Cloud migration: a step-by-step plan for business

Moving email, files, servers or business systems to the cloud is a task most companies face sooner or later. Migrations rarely fail because of the cloud itself. More often it is the plan: forgotten dependencies between systems, a bill nobody expected, downtime during working hours or no way back.

Below is a step-by-step cloud migration plan for business: from the inventory to cost optimisation after the move.

What cloud services are: IaaS, PaaS and SaaS

The US National Institute of Standards and Technology (NIST) defines three cloud service models. The model determines what the provider does and what your team does:

Model	What you get	What you manage	Examples
IaaS — infrastructure as a service	virtual servers, storage, networks	operating systems, applications, data	virtual machines in AWS or Microsoft Azure
PaaS — platform as a service	a ready environment: databases, application platforms	applications, settings, data	managed databases
SaaS — software as a service	a ready application	settings, users, data	Microsoft 365

By deployment model, clouds are private, public or hybrid. A private cloud is infrastructure for one organisation (more), a public cloud is provider resources shared by many customers, and a hybrid cloud combines both.

Important: the cloud does not take all responsibility off your hands. In the shared responsibility model described by Microsoft, whatever the service type, you keep responsibility for data, accounts, access management and user devices.

Step 1. Goals and inventory

Start with why the company needs the cloud: transparent costs, resilience to outages, faster launch of new services, remote work. The goals define what counts as a successful migration.

Then the inventory:

servers, applications, databases and the links between them: which system talks to which;
integrations with external services, banks, counterparties;
licences and their terms of use;
the business owner of each system;
the acceptable downtime (RTO) and acceptable data loss (RPO) — how to define them is covered in “Blackouts: how to keep business IT running”;
which data is personal or regulated — this affects the choice of platform and region.

Record your current costs separately: hardware, power, premises, licences, administrators’ time. Without this baseline you cannot compare the options fairly.

Step 2. A strategy for each system

AWS describes seven migration strategies in its guidance — the “7 Rs”. They make a handy vocabulary for deciding on each system:

Strategy	What it means	When it fits
Retire	the system is no longer needed	nobody uses it or its functions are duplicated
Retain	the system stays where it is for now	it depends on on-site hardware, was recently upgraded or is not ready to move
Rehost	the virtual machine moves unchanged (“lift and shift”)	speed matters and optimisation can wait
Relocate	the virtualisation environment moves to its cloud version	many servers on one platform
Repurchase	switch to a SaaS product	for example, replacing an in-office mail server with Microsoft 365
Replatform	some components move to managed services	for example, moving a Microsoft SQL Server database to a managed database
Refactor	the application is rebuilt for the cloud	scaling and fast releases are needed and the other options do not fit

AWS calls refactoring the most complex and costly strategy and, for large migrations, recommends moving the system first and modernising it once it is in the cloud.

Step 3. Choosing a platform

Compare platforms on more than price:

Services. Does it have the databases, backup, monitoring and security tools you need?
Region and data location. Where the data will physically be stored; for systems with personal data this is a legal question. If you are considering the EU, read “Moving servers to the EU: when it makes sense”.
Compatibility. How the platform works with your stack: VMware or Hyper-V, Active Directory, Microsoft SQL Server, Oracle.
Licences. Can your existing licences move, or will you need new ones?
Support and exit. SLA terms, support language and response time, how to get your data back if you change provider.

Not everything has to go to a public cloud. Critical or regulated systems can stay in a private cloud, while flexible workloads run in a public one. How we approach that choice: cloud solutions.

Step 4. Costs without surprises

Don’t copy servers one-to-one. Virtual machines in the office are often sized with headroom. In the cloud you pay for allocated resources, so size them by actual load.
Count everything that is billed. Besides servers: storage, snapshots, backups, outbound traffic, licences, support.
Set budgets and alerts. Large cloud platforms let you set a budget and get alerts as spending approaches it.
Name an owner for cloud costs. Without one, the bill grows unnoticed.

Step 5. Security — before the first move

Accounts and access. Multi-factor authentication, separate admin accounts, least privilege.
Network. A secure connection from the office to the cloud, segmentation, a next-generation firewall — more in network security and NGFW.
Logging and monitoring. Send events from cloud resources to security monitoring from day one — SOC as a Service.
Backup. The cloud does not cancel the 3-2-1 rule: you are responsible for your data, so keep copies both in the cloud and outside it. How we build backup: IT infrastructure.

Step 6. Pilot and migration

Pilot. Move a non-critical system, measure performance, latency and cost, test backup and restore.
Waves. Group systems by dependencies: what works together moves together.
Maintenance windows. Agree the timing with the business and warn users.
Cutover. Sync the data, lower DNS record TTLs in advance, freeze changes to the system during the move.
Verification. The system owner confirms that everything works against an agreed list of checks.
Rollback plan. Don’t switch off the old system until the new one has run for an agreed period without problems.

Step 7. After the migration

Update documentation, network diagrams and instructions.
Review the first bills and adjust resource sizes.
Decide what to do with the old hardware: retire it or use it as a backup site.
Test restores from backups regularly.

Common mistakes

Moving everything as is without a dependency map — and breaking integrations.
Counting only servers and forgetting traffic, backups and licences.
Assuming the provider will back up and protect the data on its own.
Having no rollback plan.
Not naming an owner for cloud costs.

Cloud migration checklist

How Bereg-IT can help

We inventory your systems and the dependencies between them, record availability and security requirements, compare platforms by requirements, budget and risks, and explain the choice. Then comes a migration plan with the order of moves, maintenance windows and a rollback plan, the migration itself, verification and support afterwards. If some systems should stay in a private cloud, we combine it with a public cloud in a hybrid setup. You can start with a consultation or an audit.

The first consultation is free. Send a request and we will assess what is worth moving, and where, for your business.

Sources

NIST SP 800-145, The NIST Definition of Cloud Computing (2011) — service models (IaaS, PaaS, SaaS) and deployment models: https://csrc.nist.gov/pubs/sp/800/145/final
AWS Prescriptive Guidance, About the migration strategies — the “7 Rs”: https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
Microsoft Learn, Shared responsibility in the cloud — division of responsibility between customer and provider: https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility