Moving an application to the cloud is often sold as a lift from one place to another. Done that way, you get the same fragile system on more expensive hardware. A migration that is worth doing has five stages, and a proposal should account for each.
1. Review
What does the application consist of, where does its data live, and how is it used? Usage history matters: the busiest hour of the busiest day decides how the new platform is sized.
2. Design
A written architecture that separates the layers, such as web, application, background jobs and database, so each can be scaled or replaced on its own. It should say how the system survives the loss of a server or a data center.
3. Build alongside
The new environment is built while the old one keeps running. Servers are created from scripts, not by hand, so the environment can be rebuilt identically. Source code moves into version control if it is not there already.
4. Test
- The application is installed and any faults caused by the move are fixed.
- The platform is load tested against real usage and resized.
- The people who know the software best confirm that it behaves correctly.
5. Cut over and hand over
Traffic moves to the new platform at a planned time, with a way back if needed. The old environment is kept for a short period, then retired. Your team is trained to run what has been built.
Questions to ask
- Who decides the platform is ready to launch?
- What support is included after go-live, and for how long?
- Will we be able to operate this ourselves?
- What will it cost to run each month, and what would make that change?
Related service: Cloud computing.