Migrating to IaaS: a step-by-step infrastructure plan

A safe IaaS migration moves in controlled waves: discovery, target design, landing-zone preparation, pilot, rehearsal, cutover and stabilisation. The highest-risk shortcut is to copy virtual machines “as is” without a dependency map, acceptance criteria or a tested rollback.

IaaS changes how compute, network and storage are provisioned. It does not remove the customer’s responsibility for applications, data, access, configuration and much of day-to-day operation.

Confirm the objective first

State a measurable reason for the move:

• provision environments for new projects faster;
• absorb seasonal demand without hardware procurement;
• replace ageing infrastructure;
• build a recovery environment;
• reduce recovery time;
• separate environments and responsibilities.

“Move to cloud” is not an architecture objective. Before the project, validate the model using our comparison of IaaS and an owned data centre.

NIST SP 800-145 defines IaaS as a model in which the consumer obtains compute, storage, network and other fundamental resources while retaining control of operating systems, applications and selected networking components. Reflect that boundary in a responsibility matrix.

Stage 1: inventory and dependencies

For every workload, collect:

• owner and business criticality;
• servers, operating systems, versions and licences;
• CPU, memory, storage, IOPS and network profile;
• databases, file shares, queues and external APIs;
• firewall rules, DNS, certificates and service accounts;
• maintenance windows, RPO and RTO;
• data placement and protection requirements;
• current cost and seasonality.

Automated discovery helps, but owners must validate the result. A rare batch transfer or manual export may not appear during a short observation window.

Build a dependency graph and group systems into waves. The first wave should be neither the most critical workload nor a trivial isolated VM; choose something representative and reversible.

Stage 2: choose a workload strategy

Applications do not all need the same treatment:

Strategy	Meaning	Suitable when
Rehost	Move with little application change	Time matters and architecture is compatible
Replatform	Make limited platform changes	Managed components reduce operations
Refactor	Redesign the application	A strong business case funds the change
Retain	Keep it in place temporarily	Dependencies or constraints are not ready
Retire	Decommission it	The system no longer delivers value

Rehosting everything moves technical debt and old constraints into IaaS. Refactoring everything combines two risky programmes. Record the decision per workload.

Stage 3: build the landing zone before the first VM

Prepare the common foundation:

• project, network and segment structure;
• routing, VPN or dedicated connectivity;
• identity federation, MFA and roles;
• keys and secret management;
• hardened base images;
• central logs, metrics and audit events;
• backup and retention policy;
• tags for owner, environment, service and cost centre;
• quotas and protective limits.

Do not postpone infrastructure observability until after migration. Comparable measurements before and after cutover are how the team proves that the service did not regress.

Stage 4: pilot and rehearsal

A pilot should prove more than startup:

1. deployment through repeatable automation;
2. connectivity and DNS;
3. user and service-account access;
4. performance under normal and peak profiles;
5. backup and a test restore;
6. patching, monitoring and incident handling;
7. cost based on actual consumption;
8. rollback to the source environment.

Run at least one complete rehearsal before cutover and record its duration. Find manual steps and ambiguity before production traffic depends on the new platform.

Stage 5: move data

The method depends on data size, change rate and RPO:

• backup and restore is simple but needs a window;
• replication shortens downtime but complicates consistency;
• export and import works for bounded datasets;
• file synchronisation requires deletion and permission controls;
• application-level dual write is the most complex and needs strict reconciliation.

Define the write-stop point, final sync and integrity checks. The plan must explain what happens to transactions during cutover and how replay is deduplicated.

Stage 6: cutover and rollback

For the change window, prepare:

• a change freeze and approved exceptions;
• a named go/no-go decision role;
• exact timeline and communication channel;
• an advance DNS TTL reduction where DNS switches traffic;
• smoke tests and end-to-end business checks;
• rollback conditions and last safe rollback time;
• queue-drain and reconciliation procedures.

Rollback cannot be only “point DNS back”. Once the target accepts writes, the team needs a way to return those changes or prevent them until the decision is final.

Stage 7: stabilise and optimise

Keep an enhanced-observation period after cutover. Compare latency, errors, resource use and cost with the baseline. Then:

• remove temporary access and network rules;
• update the CMDB, diagrams, runbooks and DR plan;
• confirm backup and recovery;
• add budgets and cost alerts;
• commit stable capacity only after measurement;
• decommission source resources through an approved process.

Do not remove the source environment until the rollback period and formal acceptance are complete.

Acceptance criteria

• Critical business journeys pass.
• Data reconciliation meets the agreed method.
• Performance remains within its threshold.
• Logs, metrics, traces and alerts work.
• A test validates RPO and RTO.
• Access matches the role matrix.
• Cost is attributable to services and owners.
• Runbooks and the disaster recovery plan are current.
• Rollback is either available or formally closed.

Frequent mistakes

• Moving workloads with unknown dependencies.
• Using public endpoints instead of a designed network.
• Copying old privileges without review.
• Estimating cost from CPU and memory alone.
• Testing backup for the first time after cutover.
• Treating DNS as an instantaneous switch.
• Shutting down the source before reconciliation.
• Treating a health check as business acceptance.

Next step: Logic Telecom can help inventory workloads, design the target environment and sequence migration waves. Begin with a pilot that proves performance, recovery and rollback; those outcomes matter more than merely starting a virtual machine.