Front-end migration in an Agile process

Question

In our organisation, we're planning on migrating a Single-Page Application (with a complex back-end) to another Front-end technology (Angular to React). We'd like to procede with an Agile mindset by migrating progressively (page by page) and deploying frequently.

However, we're in a bit of a conundrum as to how to procede, and we'd like some advice or feedback from the community. Here's are some constraints that I tried to summarize here :

• UX : Roaming from an Angular page to a React page degrades the user experience: instead of a single-app experience (where the header & sidebar doesn't reload), the user experiences the page as a full reload.
• Technically: we can solve this by enclosing an Angular page into a React page, but it induces a lot of risks in session management, js/css overload... The Angular app is also heavily coupled with the back-end, and one of the migration's goal is to decouple it
• Methodology : Working on a 9-month redesign before delivering puts us in a great risk, as there is little user feedback. We're keen on the frequent delivery and feedback cycle that worked so well for us.
• New features : We also have to deliver new features to respect our engagements. Initially, we wanted to connect a page migration with new features, and resolve our migration roadmap with our new features roadmap

There's a paradox between a progressive migration process that is methodologically sound, but that is technically risky and degrades the UX during the transition phase. We may think about living with some of these constraints but we'd love to collect some feedback. I hope that the question is appropriate for this site also. Have you ever experienced this situation before? Thanks!!

Answer 1

Here is how I've seen this work in the past:

First, don't view it like a Lift-and-Shift project. In general, "migration" projects are problematic because you make two assumptions that are both wrong in 90+% of migration projects.

1) You know all the work that needs to be done and how it all functions. You almost never do. People squeeze in features over the years and forget decisions that were made in the original design. I've never worked on a migration project that didn't balloon due to "discovered" complexity.

2) The needs of the user today are the same as the needs of the user originally. If this were true, there would be no good reason to migrate. Many needs will be the same or similar, but we're always surprised by how many aren't.

Instead, look at it like a new application that you have a lot of experience it. Look for user segments or problem areas that you can deliver existing, improved, and new functionality that will deliver high amounts of value quickly. For example, maybe a group in accounting had to generate a report and because of the changes in law, they have a dozen work-arounds to get the information they need the way they need it. That team will likely tolerate the relatively minor inconvenience of logging into two different systems so that they can generate that report faster.

In my experience, shifting this mindset opens the team up to think creatively about how to tackle many of the constraints you mention.