3

I need to come-up with a project plan for migrating a legacy web application to a ReactJS based application.

The legacy web application is written in Vanilla JS, HTML, CSS and there are approximately 4000 html files with NodeJS as backend (so its a fairly big application).

Now migrating such a big application to a new technology stack will need some kind of planning to avoid bottlenecks at a later stage in the project execution phase.

Some challenges with this migration will also involve convincing the stakeholders about the benefits of the migration + there will also be a learning curve needed for the technical(developer) staff.

Also since the migration effort might take some time to complete, we will also need to keep supporting the existing legacy application in the meantime. So the agility for the existing application needs to continue in parallel to the new migration effort.

Any ideas / references / insight here will be highly appreciated in planning such a complex project.

What I have already researched:

  • Searched on Google (but didn't find a suitable guideline for a migration project). All the references are pointing to a new project planning aimed at "from-the-scratch" development.
Improve this question
2
  • If you don't already know the benefits, then it's possible that there are not enough, and the devs simply want it because 'react is the thing to program in now'. If you're running a site that needs to appear in google searches, there's a god change no one involved is informed enough to do this safely
    – New Alexandria
    Feb 23, 2019 at 23:13
  • @NewAlexandria that is not the case here. We(engineering & product teams) are well aware of the benefits related to the migration. The challenge is to plan the project in a well organised manner.
    – kcak11
    Feb 24, 2019 at 8:14

4 Answers 4

Reset to default
2

Also since the migration effort might take some time to complete, we will also need to keep supporting the existing legacy application in the meantime.

I take it from this statement that the new development will be done in parallel with the existing application, rather than replacing components one at at time. My answer will reflect this.

Use what you have now as a guide

The existing system can be analysed to produce a feature list for the new application. It will also be useful to think about the relative value of the features in the existing system. For example, which is the most important feature? Which features are nice to have and the users could do without (perhaps just temporarily)?

Now turn this analysis into a prioritised backlog of work. The most important mandatory features will be at the top of the backlog.

Secondly, consider producing a suite of (ideally automated) regression tests for the most important features. These tests can be run against the existing system and show to work. The intention will be that the tests operate at the UI layer and so can be run against the legacy system or the replacement system.

These regression tests will help the development team work with confidence while they progress along the learning curve of the new technology.

Build the support of the stakeholders by delivering incrementally

The stakeholders will often get nervous if the new development absorbs resources while showing no results. As you have a prioritised list of features, try to deliver working software at regular increments. For example, perhaps the first working release will include just the top 5 features of the application.

Work with just one backlog

It is a good idea to combine the work on the new application with any work required to maintain the existing, legacy system.

Have just one backlog and prioritise maintenance tasks alongside new development items. It may be that some maintenance tasks are not all that urgent and can be prioritised below new development tasks. Your backlog might look like:

Fix legacy bug #7

Generate quarterly report from legacy system

Feature #2 on new system

Feature #8 on new system

Fix legacy bug #12

Consider a staged switchover

If possible, try and avoid a big bang style switchover to the new system. Can you run the new application in parallel with the legacy system? Could it be run as a beta with a subset of your users?

If you deliver the new application incrementally and run in parallel then you can greatly reduce the risk associated with the switchover.

Improve this answer
2

A few things to consider:

Organize Around Capabilities, not Features

X User will be able to do Y. This approach let's you fulfill and validate user needs quickly. This is also a great way to get user experience refinements without incurring extra cost. It also will help you avoid recreating things that aren't in use.

Plan Around User Segments

It is hard for users to keep using two systems. Focusing on user segments lets you get some users cut over earlier in the project. This goes over great with stakeholders!

Prioritize

"Make it do everything the last one did." Is the most common and most useless phrase in these projects. When I've worked on these projects in the past, sometimes it was even worth the cost to build out some logging to see which capabilities were actually being used.

Improve this answer
1

We're planning out something similar in my organisation.

Step 1 is to separate all your business logic from your interface/display logic. You can do that in your current application before starting the new one. This approach has a few advantages:

  1. It's a good idea anyway. Even if you don't proceed with the bigger project, you'll benefit from the refactoring.
  2. When you start the new project, you'll share a big chunk of code between the current and new codebases which will make parallel development easier.
  3. It will reduce the length of time you must maintain two applications.

Step 2 is to select a self contained section of your application to migrate. We picked the administrator section of our application because it doesn't share any common screens or functionality with the rest of the application. Once you've successfully migrated a small section of your application, you can delete the code for the old version and pick the next thing to migrate.

Improve this answer
1

I have some experience with migrations. What I can suggest is the following.

FIRST and very first, create a product oriented work breakdown structure. Don't do this alone, do it with the support of the team.

About the WBS, I'd put in the first level of my WBS the following:

  • Website: So you can decompose further the features to deliver (frontend, backoffice, backend, etc)
  • Governance: My applications may impact your governance, you probably have to update this and deliver the new governance and business processes
  • Reporting: As you may impact the datalayer, or new report needs may appear
  • Learning cycle: As new capabilities/skills are needed, you will probably have to organize some trainings and coaching

SECOND: Create your planning Regardless if you project is agile or not, this are the steps I follow to create my plannings:

  • Use the work breakdown structure that you just created to outline the schedule

  • Ask to your team what needs to be done to deliver what is in the work breakdown structure

  • Identify with your team in which sequence they suggest to do the activities

  • Get to know what the team needs to work on the tasks and to deliver what is in your scope

  • Get the first estimations of the effort and duration

  • Consolidate all the information in the project management tool you will use to manage the project schedule

You can get more details about in my post "How to create a project schedule", where you will also find information about how to create a product oriented WBS.

I hope this helps you.

Cheers, Falcon

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.