Cloud Migration Steps That Actually Work in Production

The helpdesk application has moved, the warehouse is only half cut over, and the SAP environment is still sitting on the critical path. The original plan allowed six months. Fourteen months later, the programme is still expanding because nobody established the application dependencies, identity sequence, rollback triggers, or cloud cost guardrails before production work began.

That pattern is common in mid-market and enterprise migrations. Teams start with a platform diagram or a preferred provider, then discover that authentication, batch jobs, data residency, licensing, and recovery requirements decide the order of work. The practical answer is an ordered set of cloud migration steps with a decision gate between each one, not a checklist that treats every workload as interchangeable.

Table of Contents

• The Cloud Migration Reality Most Guides Skip
• Step One, Assess Before You Architect
  • Build evidence instead of collecting opinions
• Step Two, Pick the Right Migration Path per Workload
• Step Three, Design the Target Cloud Architecture
• Step Four, Sequence Waves Around Dependencies
  • Make each wave a controlled experiment
• Step Five, Test and Validate Every Wave
  • Test controls as part of the workload
  • A strangler cutover for order management
• Step Seven, Run, Optimise, and Decommission

The Cloud Migration Reality Most Guides Skip

The textbook version of migration is tidy. Assess the estate, choose a provider, move applications, and optimise the result. Production environments aren't tidy. A seemingly independent application may depend on an identity provider, a shared database, an old network route, or a batch process owned by another team.

The most expensive mistakes usually happen before the first cutover. An assessment based on interviews misses traffic that nobody remembers. A lift-and-shift decision made before licensing and cost modelling creates an expensive temporary architecture. A cutover plan without a measurable rollback trigger turns a change window into a negotiation under pressure.

Practical rule: A workload isn't ready because it starts in the target cloud. It's ready when its dependencies, controls, performance, recovery path, and rollback decision have all been tested.

The sequence that works in practice is:

1. Assess the estate and its dependencies.
2. Select a migration path for each workload.
3. Design the target architecture and control boundary.
4. Sequence waves around shared dependencies.
5. Test and validate every wave.
6. Cut over with a paired rollback plan.
7. Run, optimise, and decommission deliberately.

Steps five and six belong together operationally, but they deserve separate decision gates in the runbook. Validation proves that a workload can move. Cutover proves that the organisation can operate it under real traffic.

Cost discipline also starts before the first resource is provisioned. Teams working through budgets, ownership, tagging, and forecast variance can use these tips from Credit for Startups as a practical reference while defining guardrails. The important point is simple, cloud migration isn't complete when infrastructure changes location. It's complete when the new environment is supportable, compliant, observable, and financially understood.

Step One, Assess Before You Architect

A migration can fail before the first resource is provisioned. If the team cannot identify ownership, dependencies, recovery needs, and operating constraints, a target-state diagram only gives those assumptions a polished shape. Start with three working artefacts: an inventory, a dependency map, and a readiness baseline.

The inventory should include servers, databases, storage volumes, scheduled jobs, certificates, queues, integration endpoints, and externally managed services. Add an accountable owner, business criticality, data sensitivity, licence status, recovery requirement, and maintenance window to each record. Discovery agents can collect technical details, but the platform team must reconcile them with the CMDB and business ownership records.

Build evidence instead of collecting opinions

Dependency mapping is the first validation gate. Interviews describe intended architecture. Traffic captures, code analysis, database connection logs, job schedules, and authentication events show what runs. Record synchronous and asynchronous relationships, including reporting extracts and file transfers that application diagrams often omit.

Baseline performance under representative load, not during a quiet afternoon. Record normal behaviour, peak conditions, batch processing, storage growth, and failover behaviour. Document each workload's exit cost as well, including licences, circuits, hardware contracts, data transfer, specialist support, and any dual-running period.

The readiness baseline combines this evidence with the constraints that shape architecture. Record identity providers, network paths, encryption practices, residency requirements, compliance obligations, operational skills, and gaps in cloud ownership. Identity deserves an early gate. A workload should not enter a migration wave until its users, service accounts, privileged access, and recovery access have a tested path in the target environment.

Illinois shows why preparation also belongs in governance. Its Enterprise Technology Management programme included disaster-recovery planning and infrastructure readiness for a projected cloud-migration period in 2026 to 2027, as described in the NASCIO Illinois Enterprise Technology Management profile.

Use infrastructure as code after the inventory and ownership model are credible. A primer on what infrastructure as code means can align terminology, but code will reproduce an incomplete dependency map just as consistently as a complete one.

Assessment ends at a decision gate, not when the spreadsheet is complete. Each workload must have a documented classification for business criticality, compliance constraints, technical debt, data sensitivity, and migration complexity. Those classifications feed path selection and wave design. If the team cannot explain a workload's category and its evidence, architecture work should wait.

Step Two, Pick the Right Migration Path per Workload

Migration path selection is the central architectural fork. Applying one method to the entire estate is convenient for programme reporting, but it ignores the different constraints carried by an ERP, a customer portal, a reporting database, and a development environment.

Lift-and-shift, or rehost, is appropriate when the date matters more than immediate modernisation. It can suit an ERP core, a regulated data store, or a workload approaching a hardware or licensing deadline. A vendor-led rehost can reduce execution risk when the scope, tooling, target platform, and operating model are fixed in advance. It doesn't transform the application, and selling it internally as a transformation creates the wrong expectations.

Replatforming makes targeted changes without discarding the application's core design. Examples include moving a self-managed database to a managed equivalent, adopting cloud storage, or changing the runtime while preserving application behaviour. This path earns its place when a limited change removes a fragile operational responsibility or improves portability.

Refactoring changes the design so the workload can use cloud-native operating models. It makes sense where elasticity, managed services, or independently deployable components are central to the business case. A rewrite should be rarer still. If the current design blocks every viable future path, replacement may be justified, but a rewrite hidden inside a migration programme is a common source of uncontrolled scope.

Classify every workload against six criteria before drawing its target architecture:

• Business criticality, including customer and revenue impact.
• Compliance constraints, including residency, retention, and audit requirements.
• Licence portability, particularly for proprietary databases and ERP platforms.
• Technical debt, including unsupported operating systems and coupled code.
• Source-platform cost trajectory, including contracts and specialist operations.
• Team runway, meaning the time, skills, and capacity available for change.

Illinois's SAP procurement illustrates the regulated-environment version of this decision. The state required a systems integrator to move its SAP NS2 environment from Virtustream to Microsoft Azure, a vendor-managed migration pattern centred on rehost or replatform execution and post-migration operations. The SAP systems integrator solicitation is a useful reminder that a core ERP move needs explicit scope and operational accountability.

Step Three, Design the Target Cloud Architecture

A target architecture should record binding decisions, not merely present attractive boxes and arrows. The design must explain where data lives, how identities are trusted, how networks connect, which services are managed, and how operators will detect and recover from failure.

Region selection comes first for workloads with residency or latency constraints. Illinois policy reporting identifies Chicago's data-residency ordinance and discusses a proposed United States storage requirement for state data under HB3574. The same reporting discourages concentrating data with a single vendor and single location, so Illinois migration planning needs to consider legal location, backup geography, portability, and concentration risk together, as outlined in this Illinois policy and procurement report.

Infrastructure locality can also shape a hybrid path. A directory of Illinois data centres lists facilities across markets including Chicago and Aurora, which may matter when a team needs colocation, private connectivity, or a gradual transition rather than an immediate removal of local infrastructure. The directory is not an architecture decision by itself, but it highlights why locality assumptions should be tested rather than inherited from a generic cloud diagram.

Identity needs its own boundary decision. Choose a cloud-native directory federated to legacy identity where possible, or define a hybrid trust model when Active Directory dependencies can't be removed immediately. Migrate identity and access patterns early, because later applications inherit the authentication, authorisation, service-account, and secrets decisions.

Network design should be equally explicit. A hub-and-spoke topology with centralised egress can suit a larger estate. A transit gateway equivalent can simplify shared connectivity. A flatter design may be reasonable for a small environment, but only if security boundaries and ownership remain clear. The correct answer depends on blast radius, connectivity, operations, and compliance, not on architectural fashion.

Managed databases, object storage, central logging, secrets management, and observability should be defaults where they reduce undifferentiated operations. Keep self-managed runtimes when the application needs kernel-level control, a specific certification, or a capability unavailable in the managed service. A reusable reference pattern, supported by cloud architecture and infrastructure solutions, should include mandatory modules for logging, secrets, identity, network controls, backups, and alerting so every migration wave starts from the same baseline.

Step Four, Sequence Waves Around Dependencies

The migration graph, not the organisational chart, should determine wave order. Once the dependency map exists, mark workloads that rely on identity, DNS, shared databases, integration brokers, network paths, and scheduled exchanges. A team preference to move the easiest application first isn't a valid reason to move it before the platform services that application needs.

Identity and shared platform services usually belong near the front of the programme. They may feel less visible than an application, but every later workload benefits from consistent authentication, secrets handling, logging, and network controls. Moving them early also exposes federation and service-account problems while the blast radius remains manageable.

Make each wave a controlled experiment

Start with internal tools, development environments, and low-risk services that exercise the reference architecture without threatening revenue operations. Use those waves to validate the discovery data, provisioning code, monitoring, support model, and cutover runbook. A successful early wave isn't just a migrated application. It's evidence that the organisation can repeat the process.

Group later workloads by dependency and blast radius. Customer-facing systems, revenue platforms, shared databases, and ERP integrations generally need mature change control and proven recovery procedures. Illinois's own modernisation sequence offers a concrete example of this layered approach. In its annual report, the Department of Innovation and Technology described migrating 52 applications to ILogin, its enterprise single sign-on platform, protecting personal information for approximately 5 million resident accounts, and moving its finance ERP solution to DoIT-managed cloud hosting. These results are documented in the 2025 DoIT annual report.

Every wave needs an exit gate before the next one opens. Require performance parity against the agreed baseline, successful integration tests, security-control verification, recovery evidence, operator sign-off, and a rehearsed rollback. Don't open parallel regional waves until the runbook has held twice in one region. Parallelism looks efficient on a roadmap, but it multiplies ambiguity when the first failure reveals a flaw in the process itself.

Step Five, Test and Validate Every Wave

A workload can start in the target environment and still fail during realistic traffic, a batch window, downstream latency, or database promotion. Testing is the release gate for each migration wave, not a final formality after cutover.

Begin with a source-environment baseline. Record response time, throughput, error behaviour, resource consumption, batch duration, and recovery behaviour under representative conditions. Run the same test suites in the target environment, using the same business transactions and comparable load profiles. If the source baseline is unreliable, improve the measurement first. Otherwise, the team will argue about whether the cloud environment is better without having a dependable reference.

Functional parity requires more than loading a page successfully. Synthetic transactions should cover the user journeys that matter. Contract tests should verify upstream and downstream interfaces. Data checks should compare record counts, checksums, aggregates, referential integrity, and business-critical queries where the workload permits. Cloud latency also exposes assumptions hidden by a low-latency local network, especially in chatty applications and integration-heavy ERP environments.

Test controls as part of the workload

Security testing must reflect the target reference architecture. Review IAM policies, privileged access, service identities, network segmentation, encryption at rest and in transit, secret rotation, logging, and alert delivery. A perimeter review will not reveal an overly broad role or a secret copied into an application configuration file.

Stateful workloads require deliberate failover exercises. Promote the database, rebuild caches, restore dependent services, verify application reconnect behaviour, and record the person authorised to make the recovery decision. A replica is not evidence of disaster recovery. The team must execute the recovery path and confirm that the business can operate afterward.

The cutover method should follow the workload. A stateless internal service may tolerate a big-bang change. A high-value application may need parallel operation. A data-heavy system may require continuous replication and a short final synchronisation. A strangler approach can move bounded capabilities while the existing system continues serving the remaining functions.

A strangler cutover for order management

For an order management system, pre-warm the target application, validate database replication, and confirm that observability is receiving target-side signals. Route a controlled portion of traffic through the new path, hold the validation window, and compare order creation, payment hand-off, inventory updates, fulfilment messages, and customer notifications. Increase traffic only after the application, data, and operations owners agree that the evidence meets the gate.

Define traffic increments in the runbook before the change window. Each stage needs a validation window, a decision owner, and a call-tree entry. The rollback procedure must repoint traffic, stop or isolate writes where required, reconcile data created during the trial, and confirm that downstream consumers are not processing duplicate events.

Rollback is a contract, not a sentence in a change ticket. Set a measurable trigger, such as an error threshold, latency breach, data drift, or failed reconciliation. Name the person who can invoke it, document the required recovery time objective, and provide a tested route for DNS, identity, and replication changes.

The rollback window closes when the old path can no longer accept consistent writes, not when the first successful request reaches the new system.

Illinois's Enterprise Technology Management programme included a full application failover and disaster-recovery objective for the state data centre by Q4 2025, according to the NASCIO profile cited earlier. That sequencing matters. Resilience testing belongs before production migration, because an ERP cutover is the wrong place to discover recovery assumptions.

Illinois State University provides another example of staged execution. Its PeopleSoft-based student information and HR/payroll systems moved through an ERP layer first, followed by backup and disaster-recovery workloads to AWS. That sequence enabled retirement of an offsite data centre and produced an operational improvement with approximately 30% lower total ownership cost, as described in the AWS Illinois State University case study. The lesson is not to copy the same platform. Core transaction systems and infrastructure retirement can be separate validation decisions, with different owners and acceptance evidence.

The common failure is treating rollback as theoretical. Teams shift traffic, observe a few successful requests, and close the old environment before data consistency and downstream processing are understood. Keep the rollback path live until the agreed evidence, reconciliation, and ownership gates have passed.

Step Seven, Run, Optimise, and Decommission

The day after cutover is the start of a new operating phase. Three workstreams should run concurrently: reliability hardening, cost optimisation, and controlled decommissioning.

Reliability work closes the gaps exposed by real traffic. Tune service-level objectives, improve dashboards, test alert routing, remove noisy signals, and run failure drills against the components that carry the greatest operational risk. A workload may have passed migration testing while still lacking useful saturation indicators or a clear owner for a degraded dependency.

Cost work needs named owners and a weekly operating rhythm. Review rightsizing, commitment options, storage tiers, idle resources, data transfer, and allocation tags against actual usage. In one common failure pattern, a customer portal moves successfully but sends excessive logs across services and regions, creating unexpected egress costs. Sampling, routing logs to the right sinks, and separating operational retention from analytical retention can correct the design without weakening the signals operators need.

The cloud cost optimisation strategies guide is useful when turning those reviews into repeatable controls rather than a monthly finance report. Cost ownership belongs with engineering, product, finance, and platform teams together, because a cheaper architecture that harms reliability isn't an optimisation.

Decommissioning should follow evidence, not schedule pressure. Age out DNS and routing dependencies, verify cloud-only monitoring, confirm backups and retention, terminate unused licences and circuits, and document data-eradication responsibilities. Physical equipment needs its own compliance process, particularly when legacy mainframe or storage systems contain regulated data. Teams retiring those assets can review mainframe hardware disposal compliance before equipment leaves controlled custody.

Keep a documented shadow period before shutting down legacy infrastructure. During that period, compare support tickets, reconciliation reports, monitoring paths, and business outputs. Only then should the final shutdown approval terminate the old environment and close the migration workstream.

Ryware provides senior-led cloud architecture, migration execution, infrastructure as code, data platform engineering, performance testing, and reliability support for teams moving complex production workloads. Visit Ryware to discuss an evidence-led migration plan, dependency assessment, cutover design, or post-migration optimisation programme.