The last post was about what to avoid, this post is about what you can do to make a migration successful.

Sequencing is key

With any large initiative, the natural impulse is to throw a lot of people at it. Avoid this impulse at all costs. At the beginning of the project, it is better to have a small team of your crack developers and senior engineers and PM’s to focus on building a skeleton of what the end state would be like.

Building a skeleton with a small team gives them the space to experiment in building the right abstractions and testing a few ideas out. This initial core team can then be used as the kernel to scale up the resources on the team. Start small, experiment and then expand.

Resource the team appropriately

On the other end of the spectrum, you have to recognize that system migration takes a good chunk of resources. It is foolish to expect that if a team of 10 engineers had built the legacy system that a team of 10 or fewer engineers can build the new system. You are untangling years of complexity into something new – this is going to take more time and people. Plan appropriately.

Ruthlessly prioritize

Development on the existing legacy stack has to slow down to a trickle. Without this constraint, the team is just going to be chasing its tail and will never be able to launch the new system. The only way to move forward is to figuratively burn the old system down behind you.

Transition users in phases

Transition users over to the new platform in phases. Don’t wait for the entire system to be feature complete and then transition users over. Find a small segment that you can migrate and quickly do it. You want the new platform to experience real user traffic as soon as possible.

Yes, there is a hit to the ops teams as they have to work in two systems for a while – but it’s worth it. Getting users to use the new system earlier enables the team to work out the kinks earlier thus ensuring a smooth eventual migration.

What do you think? Any other tips? Comment away!