Follow the strangler fig pattern, and map out every single task that is required in the migration on a whiteboard.
Write tests if you can, and set up a staging environment for V2 that you can setup and tear down easily for battle testing way before going live.
From there, break the tasks up from above into their business domains, and abstract those into new api services that the v1 system can use without any downtime.
For a frontend migration, that’s a whole different story and you would have to provide more details such as “moving from legacy Angular 1 to React 18 while it’s running”.
> Follow the strangler fig pattern, and map out every single task that is required in the migration on a whiteboard.
> Write tests if you can, and set up a staging environment for V2 that you can setup and tear down easily for battle testing way before going live.
I've successfully helped migrate a critical project and followed exactly this strategy. Older versions were being developed and run 1:1 in parallel to the newer ones until the customers got only a small downtime due the change of IP Addresses were the system was running
Write tests if you can, and set up a staging environment for V2 that you can setup and tear down easily for battle testing way before going live.
From there, break the tasks up from above into their business domains, and abstract those into new api services that the v1 system can use without any downtime.
For a frontend migration, that’s a whole different story and you would have to provide more details such as “moving from legacy Angular 1 to React 18 while it’s running”.