Before: know what you have
You cannot plan a move for systems you cannot list. Spend the first stage on discovery, and keep it read-only.
- List every server, application and database, with an owner for each
- Map what talks to what, including scheduled jobs and file shares
- Note licences, contracts and renewal dates, because they set the deadline
- Record current cost, so you can compare honestly later
- Identify data rules: where data may live and who may see it
- Find the quiet systems nobody mentions, such as a reporting server or an old FTP box
Choose a strategy for each workload
Not everything should move the same way. Pick one option per workload and write down why.
| Strategy | What it means | Often used when |
|---|---|---|
| Retire | Switch it off | Nobody uses it any more |
| Retain | Leave it where it is for now | A move is not worth the cost or risk yet |
| Rehost | Move it as it is | You need to leave a data centre quickly |
| Relocate | Move virtual machines between platforms with little change | You already run on VMware or similar |
| Replatform | Move with small changes, such as a managed database | A few changes bring big savings |
| Repurchase | Replace it with a SaaS product | A standard product does the job better |
| Refactor | Redesign it for the cloud | The application limits growth and the value justifies the work |
During: build, rehearse, cut over
- Build a landing zone first: accounts, networks, access rules and logging
- Group workloads into waves, starting with a low-risk one to learn from
- Rehearse each wave on a copy, and time the cut-over
- Agree a downtime window with the business, and tell users
- Compare source and target data before and after the switch
- Keep the old system untouched until the new one is proven, so there is a tested way back
After: operate, right-size and review
- Set up monitoring, alerts and backups from the first day
- Right-size servers to real usage within the first weeks
- Set budgets and cost alerts, and tag resources by owner
- Test a restore from backup, not only the backup itself
- Write the runbooks, and make sure more than one person can follow them
- Review the bill and security findings monthly
If you would rather not run it yourselves, a managed cloud service takes on the daily work while the accounts stay yours.
Frequently asked questions
How long does a cloud migration take?
It depends on how much you move and how tangled it is. A single application can take days to weeks, a whole estate months. The assessment gives you a timeline before you commit.
Will there be downtime?
As little as possible. Rehearsing on a copy, agreeing a window and keeping the old system running until the new one is proven keeps it short.
Do we have to rewrite our applications?
No. Many move as they are or with small changes. Rewrite only where the application limits the business and the value is clear.
What is a landing zone?
The prepared foundation in the cloud: accounts, networks, access rules and logging, set up before any workload moves in.