On-Premises to AWS Migration Checklist: Discovery, VPN, Cutover and Rollback

A practical checklist for moving server workloads to AWS while protecting application dependencies, hybrid connectivity, data integrity and business continuity.

Moving a server to AWS is technically easy. Moving a business workload without losing connectivity, data, access or operational understanding requires a migration plan that covers much more than instance creation.

This checklist is designed for organisations moving on-premises servers and business applications into AWS while retaining a hybrid connection during transition. It follows the sequence we use to turn a broad migration objective into reviewable stages.

1. Define the business outcome and migration boundary

Start by stating why the workload is moving and what must be true after cutover. Common goals include replacing ageing hardware, improving remote access, reducing dependence on one site, establishing better recovery options or preparing for application modernisation.

List what is inside the migration scope and what will remain on premises. Include servers, databases, file shares, scheduled jobs, identity dependencies, licences, integrations, backup systems and user groups. A workload boundary that exists only at the virtual-machine level is usually incomplete.

Record the acceptance criteria in business language. Users can open the application, scheduled processes complete, required reports match, printers or local devices work where applicable, and support teams can diagnose the environment.

2. Discover dependencies from evidence

Interviewing application owners is necessary but rarely sufficient. Combine their knowledge with network flows, authentication logs, configuration, job schedules and monitoring data.

For each workload document:

• inbound and outbound connections;
• DNS names, certificates and IP allow lists;
• identity and directory dependencies;
• database, file and message-queue connections;
• backup, monitoring and security agents;
• batch jobs and integration schedules;
• licensing tied to hardware, hostnames or addresses;
• business periods when interruption is unacceptable.

Unknown dependencies are a major cause of migration rollback. Keep an explicit unknowns list and close it through testing rather than optimistic assumption.

3. Prepare the AWS landing environment

The destination account should be operational before data arrives. Confirm account ownership, identity federation, administrator recovery, logging, security monitoring, budgets and support access.

Design the VPC around actual connectivity requirements. Select address ranges that do not overlap with on-premises networks or other connected environments. Define subnets, route tables, egress, private service access and DNS resolution. Decide whether workloads require public endpoints or can remain private behind controlled access paths.

Infrastructure as code makes the destination reviewable and repeatable. At minimum, document every component and the process for rebuilding it.

4. Design hybrid connectivity

An AWS Site-to-Site VPN provides two tunnels, but resilience depends on the complete path. Confirm customer-gateway capability, public IP stability, routing mode, encryption parameters, on-premises firewall rules and AWS route propagation.

Validate both tunnels individually. Monitor tunnel state and traffic, and document how routes change during failure. If the business requires stronger availability or predictable bandwidth, assess Direct Connect or a second independent connectivity path.

Plan DNS across the hybrid environment. Users and applications should resolve the intended endpoint before and after cutover without relying on undocumented host-file changes.

5. Select a migration method per workload

Different workloads need different transfer and cutover patterns. Rehosting may use block-level replication, while databases may use native replication or AWS Database Migration Service. File data may use DataSync, Storage Gateway or controlled copy processes.

Choose the method based on change rate, data volume, outage tolerance, application consistency and rollback needs. Record how data is protected in transit and at rest, and how integrity will be checked at the destination.

6. Build and test before production cutover

Create a test environment using representative data where permitted. Validate operating-system configuration, application startup, identity, database connectivity, integrations, scheduled jobs, backups, monitoring and security controls.

Test from the user perspective across the VPN. Infrastructure health alone does not prove that a finance, warehouse or operations workflow succeeds.

Run restore tests for the destination backups. Confirm who receives alerts and who can access the environment during an incident.

7. Create the cutover runbook

A cutover runbook should be executable by the team, not a high-level project plan. Include owners, timestamps, prerequisites, communication points, commands or procedures, validation steps and decision gates.

Typical stages are:

1. confirm backups and replication health;
2. freeze or control source changes;
3. complete final synchronisation;
4. start destination services in dependency order;
5. update DNS or routing;
6. validate technical health;
7. complete business acceptance;
8. monitor through the agreed stabilisation window.

Define the maximum time allowed for each stage before escalation or rollback.

8. Make rollback specific

"Move back if there is a problem" is not a rollback plan. State which changes can be reversed, how data written after cutover will be handled, when the source stops being authoritative and who makes the decision.

Rollback may be straightforward before destination writes begin and much harder afterwards. Use decision gates that reflect this change in risk.

Keep source systems protected until the agreed validation period ends. Decommissioning is a separate controlled activity.

9. Operate the AWS environment after migration

Assign ownership for patching, backup, restore testing, VPN monitoring, security findings, capacity, cost and application support. Update service documentation and the configuration-management record.

Review the environment after stabilisation. Migration settings are not always the right long-term architecture. Rightsize from observed use, refine monitoring and decide which workloads should remain rehosted or move toward managed services.

10. Close the migration with evidence

Capture the final architecture, asset inventory, validation results, exceptions and outstanding actions. Confirm that the business owner accepts the outcome and that support teams have the access and documentation they need.

A successful migration does not end when the AWS instance starts. It ends when the workload is usable, recoverable, observable and owned in its new environment.

Cloud Partner Hub supports on-premises to AWS migrations, hybrid VPN connectivity and the operational work needed after cutover. If you are planning a server or ERP migration, share the current environment and constraints through our contact page for an architecture review.