Cloud migration
Migrate to Amazon Web Servicesfor unmatched scalability and innovation
Moving to AWS usually means replicating servers with AWS Transform MGN and data with AWS DMS. This page explains what each one does, and what you still have to build by hand.
Servers: replicate first, change later
AWS Transform MGN, formerly known as Application Migration Service, is the usual route for a lift and shift. It replicates source servers continuously at block level, from physical machines, virtual machines or another cloud, then converts them to launch on AWS. AWS describes typical cutover windows as minutes.
Three templates control replication, launch and post-launch settings. Servers can be grouped into applications and applications into waves, so a launch or cutover can be run for a whole group. That grouping is only as useful as your dependency map, so we work out which servers talk to each other before the first wave is set.
Rehosting moves your problems along with your servers. A machine that was badly patched on-premises arrives badly patched. AWS itself frames rehosting as a first step, with replatforming or refactoring coming after, and we plan it the same way.
Databases: what AWS DMS doesn't do for you
AWS Database Migration Service moves data between engines, or between two copies of the same engine, as long as at least one endpoint is on an AWS service. AWS's best-practice guide is direct about its limits:
- It creates tables and primary keys, but not secondary indexes, foreign keys or user accounts. Those are built separately, with native tools or DMS Schema Conversion for a change of engine.
- For a full load, AWS recommends dropping or delaying indexes, referential integrity constraints and DML triggers, because tables load in groups and constraints would be violated. Triggers go back on just before cutover.
- Ongoing replication doesn't propagate items such as users, privileges and stored procedures, and AWS says it is not real-time and carries no latency SLA. A busy batch job can push lag to several minutes or longer.
- Large objects need a decision. Limited LOB mode, the default, won't carry values over the size you set, and those then have to be migrated manually. Some engines treat JSON columns as LOBs, so a low limit can truncate them.
- Truncation and rejected rows may appear only in the task log, so someone has to read it. Data validation, where supported, compares source and target after the full load.
The tracking tools have changed
AWS Migration Hub stopped accepting new customers on November 7, 2025, and AWS now points new users to AWS Transform. Older migration guides, and some proposals, still build their plans around Migration Hub, so check that yours doesn't.
What goes wrong outside the tools
- Hard-coded IP addresses and hostnames in application config, cron jobs and old scripts.
- Licences tied to hardware or a host, which may not move on the same terms.
- Outbound email, which often has to be rerouted through a mail service with its own sending reputation to build.
- Costs. Data transfer, storage and idle instances surprise teams who only compared server prices, so we set budgets and tagging on day one.
What we can show you
We have no published AWS migration case study. We do manage servers under our maintenance plans, and our backup routine runs to S3-compatible storage with tested restores, but neither is a migration programme. If you need a partner with a long record of large AWS estates, say so and we will tell you honestly whether your project suits us. Smaller application and database moves are a better fit.
AWS migration questions
Will AWS DMS move our whole database by itself?
It moves the data, tables and primary keys. Secondary indexes, foreign keys, users and stored procedures need separate handling, and you should plan and test that as its own step.
Should we rehost or rebuild?
Rehost when the deadline is about leaving a data centre and the application is healthy. Change the application first when it can't run on a supported stack anyway, since you would otherwise pay to move something you are about to replace.
List your servers and what talks to what
A rough inventory is enough to start. We will tell you which parts can be rehosted and which need work first.
We reply within one business day (IST).