A repeatable application-migration model

Supporting each team separately could not keep pace with the scale of migrating applications to a new cloud platform.

Application requirements varied, and every team needed knowledge of configuration, integrations, deployment and troubleshooting in the new environment.

I based the migration model on four principles:

• Recurring classes of problems — solving the classes of problems identified while working with the first teams, rather than one ticket after another.
• Identifying where a problem lies — establishing whether a problem lies with the platform, with the application’s behaviour in the new environment, or with a gap in knowledge.
• Carrying over application behaviour — establishing which application behaviour has to survive the platform change, and providing it by other means where moving the configuration is not enough.
• Self-service for typical cases — solutions turned into templates, procedures and documentation based on real cases, so that teams carry out typical migration steps on their own and unusual cases go to separate diagnostics.

I worked directly with the first more than 20 teams: I diagnosed application and integration errors and adapted application configuration and resources to the new environment.

Where suitable mechanisms were missing, I designed and deployed them: deployment templates, a configuration baseline depending on the application class, and mechanisms that preserved application behaviour that configuration alone could not carry over.

I turned the solutions developed with the first teams into migration procedures, documentation based on real cases, a catalogue of unusual errors, and predefined templates and workflows. Subsequent teams carried out typical migration steps on their own, and recurring problems no longer had to be analysed from scratch.

Value: migrating further teams no longer required one-to-one support in typical cases — templates and procedures handled them, and specialist support dealt with the exceptions.