Cloud migration apps: the tools that move servers, databases and applications
A cloud migration app is software that moves servers, databases or whole applications from your data centre into a cloud platform, or helps you plan that move. The main ones are low-cost native services: AWS Transform MGN, Azure Migrate and Google Migrate to Virtual Machines, supported by database, cost and monitoring tools.
Key takeaways
- Start with the target cloud's own tooling. AWS, Microsoft and Google all ship migration services that cost little or nothing beyond the infrastructure you replicate into.
- AWS Application Migration Service is now called AWS Transform MGN. Server replication is free for the first 90 days per server, then about USD 30 per server per month.
- CloudEndure Migration has been replaced by MGN, and AWS Migration Hub closed to new customers on 7 November 2025. Many older tool lists still recommend both.
- A migration app only moves workloads. You still need discovery, cost control, monitoring and policy guardrails, which are separate tools.
- Choose tools per migration strategy: rehost, replatform and refactor each need a different toolset.
What does a cloud migration app actually do?
It automates one or more of four jobs: discovering what you run, copying it to the cloud, switching users over, and proving it works afterwards. No single product does all four well, so most projects combine a native migration service with a few specialist tools.
The four jobs look like this in practice:
- Discover and assess. Inventory servers, measure CPU, memory and storage use, map which systems talk to each other, and estimate cloud cost. See our guide to cloud migration assessment tools for this step.
- Replicate. Copy disks or databases to the target while the source keeps running, then keep them in sync until cutover.
- Cut over. Stop the source, run a final sync, launch the target and point DNS and users at it. Good tools let you run test launches first without touching production.
- Operate and validate. Compare performance, error rates and cost with the baseline you measured before the move.
Which migration apps do the main clouds provide?
Each hyperscaler has a native service for moving virtual machines and a separate one for databases. Use these first, because they are supported by the cloud vendor, priced low, and understood by every partner.
AWS Transform MGN (formerly AWS Application Migration Service)
MGN performs continuous block-level replication of physical, virtual or cloud servers and converts them to run natively on EC2. You can group servers into applications and waves, run test instances, and then cut over. According to the AWS Transform MGN pricing page, the first 90 days (2,160 hours) of replication per server are free, and after that it costs USD 0.042 per server per hour. You still pay for the EC2 and EBS resources used for staging, testing and cutover.
MGN is the successor to CloudEndure Migration; the old CloudEndure Migration product page now redirects to MGN. For databases, AWS offers AWS Database Migration Service (DMS), which replicates data between engines while the source stays live.
One change catches many teams out. The AWS Migration Hub documentation states that the service has not been open to new customers since 7 November 2025, and points to AWS Transform for similar planning and tracking capabilities. If a proposal you receive is built around Migration Hub, ask which tracking tool will replace it.
Azure Migrate
Azure Migrate is Microsoft's hub for discovering, assessing and migrating servers, SQL Server databases, web apps and virtual desktops. Microsoft lists it as a free service; partner tools used inside it may charge. It also covers large offline transfers with Azure Data Box, which helps when your network link would take weeks to copy the data. Azure Migrate fits estates built on Windows Server, SQL Server and VMware, which is common in the Nordics.
Google Cloud Migrate to Virtual Machines
Google's Migrate to Virtual Machines moves VMs to Compute Engine without installing agents on the source servers. It replicates data periodically, supports test clones before cutover, and can be driven by API if you want to build your own migration factory. For moving workloads into containers, Google has a separate tool, Migrate to Containers.
Hybrid and VMware-specific tools
VMware HCX is used to move vSphere workloads in bulk or live between data centres and VMware-based cloud services, keeping IP addresses where networks are stretched. It is useful when you move to VMware running on a hyperscaler rather than converting VMs to native instances.
| Tool | Moves | Best for | Cost model |
|---|---|---|---|
| AWS Transform MGN | Physical, virtual and cloud servers to EC2 | Rehosting at scale onto AWS | Free for 90 days per server, then per server-hour, plus AWS resources |
| AWS DMS | Databases, including engine changes | Low-downtime database moves to AWS | Pay for the replication capacity you use |
| Azure Migrate | Servers, SQL Server, web apps, VDI, offline data | Microsoft-centric estates | Free service; partner tools may charge |
| Google Migrate to Virtual Machines | VMs to Compute Engine | Agentless VM moves to Google Cloud | Check current Google pricing for your project |
| VMware HCX | vSphere workloads between VMware sites | Moves to VMware-based cloud services | Licensed through the VMware offering you use |
What other tools does a migration need?
Moving the servers is the easy part to automate. Projects go over budget or fail because of cost surprises, missing monitoring and configuration drift, so plan tools for those jobs too.
Cost control
Set up tagging and budgets before the first wave, not after. Native tools such as AWS Cost Explorer and Azure Cost Management show spend by service, account and tag, and forecast the next month. Multi-cloud estates often add a FinOps platform such as Flexera One or CloudZero to report cost by team or product. The common surprises are oversized instances copied one-to-one from on-premises, test environments left running, and data transfer charges. Our cloud cost optimisation service covers this work after the move.
Monitoring and performance baselines
Measure response times and error rates before migration, or you cannot prove the new environment is as good. Datadog, Dynatrace and AppDynamics map service dependencies and track user-facing transactions across both environments during the move. Native options (Amazon CloudWatch, Azure Monitor, Google Cloud Monitoring) are cheaper but weaker on cross-environment views.
Data integration
For analytics pipelines and data that changes shape during the move, integration tools such as Informatica or Talend handle lineage, quality checks and synchronisation. Storage platforms such as NetApp Cloud Volumes ONTAP keep snapshots and replicate volumes across environments. Always reconcile row counts and checksums after the final sync.
Security and policy guardrails
Turn on configuration recording and policy enforcement in the landing zone before workloads arrive. AWS Config records resource configuration history, and Azure Policy blocks non-compliant resources at deployment time. Google Security Command Center and third-party platforms such as Prisma Cloud flag misconfigurations across clouds. This gives you audit evidence for GDPR and NIS2 from day one.
How do you match tools to a migration strategy?
Pick the strategy per application first, then the tool. The 7 Rs of cloud migration give the full list; four of them drive most tool choices.
| Strategy | What changes | Typical tools | Trade-off |
|---|---|---|---|
| Rehost (lift and shift) | Nothing in the application; servers move as they are | AWS Transform MGN, Azure Migrate, Migrate to Virtual Machines | Fastest, but keeps old inefficiencies and licence costs |
| Replatform | Swap parts for managed services, such as a managed database | AWS DMS, Azure Database Migration tooling, native backups | Some testing effort for lower running cost |
| Refactor | Application moved into containers or rewritten as services | Migrate to Containers, Kubernetes, CI/CD pipelines | Most effort, best long-term scalability |
| Relocate | VMware workloads moved to VMware-based cloud hosting | VMware HCX | Quick exit from a data centre, limited cloud-native gains |
A common sequence is to rehost first to meet a data-centre exit date, then replatform the databases and refactor the applications that change often.
How to choose a migration toolset
Score each candidate against your estate, not against feature lists. These questions separate tools quickly:
- Source coverage. Does it support your operating systems, hypervisors and database versions, including the old ones?
- Downtime. Does it replicate continuously, and can you test a launch without stopping the source?
- Scale. Can you group servers into waves and run actions on a whole wave?
- Data transfer. How long will the initial copy take on your bandwidth, and is there an offline option?
- Rollback. What is the documented way back if cutover fails?
- Total cost. Licence or per-server fees plus the staging infrastructure the tool provisions.
- Support. Who answers at 02:00 during a cutover window, and under what SLA?
Run a pilot on two or three representative applications before you commit to a toolset for hundreds of servers. The pilot shows real replication times, licence issues and performance gaps.
Example: tools used in a real AWS migration
When Opsio migrated SilverRail Technologies' Nordic branch onto AWS, the work ran in three phases: assessment, mobilise and migrate. The mobilise phase included a pilot with test migrations of selected workloads, which was used to adjust the AWS services and the migration process. Data was moved with native PostgreSQL tools under a detailed cutover plan, and cutovers ran in tight service windows to limit customer impact. AWS Control Tower, Systems Manager and Patch Manager were then put in place for governance, security and automated operations. The pattern is typical: a native migration method, a pilot, and guardrail tools in place before the platform goes live.
How Opsio helps
Opsio is an AWS Advanced Tier Services Partner with the AWS Migration Competency, with offices in Karlstad, Sweden, and Bangalore, India. We run assessments, select and operate the migration tools, and manage the platform after cutover. See our AWS migration service and Azure migration service.
Frequently asked questions
Is there a free cloud migration tool?
Yes. Azure Migrate is listed by Microsoft as a free service, and AWS Transform MGN is free for the first 90 days of replication per server. In both cases you pay for the cloud resources the migration creates, such as staging servers, storage and the target instances.
What replaced CloudEndure Migration?
AWS Application Migration Service, now named AWS Transform MGN, replaced CloudEndure Migration. It uses the same continuous block-level replication approach and is managed from the AWS console.
Can I still use AWS Migration Hub?
Only if your account already used it. AWS stopped accepting new Migration Hub customers on 7 November 2025 and recommends AWS Transform for similar capabilities.
Which tool should I use to migrate a database?
Use the target cloud's database migration service, such as AWS DMS or Azure's database migration tooling, or the engine's native tools (for example PostgreSQL dump and restore or logical replication). Native tools are often simpler for same-engine moves; managed services help when you change engine or need low downtime.
Do I need a migration partner if the tools are free?
Not always. Small, simple estates can be moved in-house with native tools. A partner adds value when you have many dependencies, tight downtime limits, compliance requirements or no staff with cutover experience. Compare options in our list of cloud migration service providers.
For hands-on delivery in India, see Opsio's replatform cloud migration practice.
About the Author
Editorial standards: This article was written by a certified practitioner, named in the byline above. We revise it when the technology or regulation it covers changes; the dates above show the latest update. Opsio maintains editorial independence — we recommend solutions on technical merit, not commercial relationships.