AWS migration in stages, each one reversible.
Moving onto AWS, between regions, or off the things quietly costing you: self-managed databases, servers doing work a managed service does better, an architecture that made sense three years ago. Planned in stages so you are never mid-jump, at a fixed price agreed before we start.
Recent engagement, B2B SaaS with real-time data-intensive workloads. Zero downtime, zero failed migrations. Full case study available on request.
Why migrations go wrong
Migrations rarely fail because of the technology. They fail because they are planned as one big weekend. Everything moves at once, the old system is switched off, and when something is wrong there is no way back. The team spends the next month fixing forward under pressure, and the next migration gets put off for years.
The other failure is quieter. The system is lifted onto AWS exactly as it was, with the same servers doing the same jobs, and the bill comes out higher than before. Nothing broke, but nothing got better either. A migration is the one moment when changing how things run is cheap, and it is a waste to spend it copying.
What we migrate
Most migration engagements are one or two of these at once.
Onto AWS
Workloads moving onto AWS for the first time. Rehosted with AWS Application Migration Service where that is enough, rebuilt on managed services where that pays back over time.
Self-managed databases to RDS
PostgreSQL or MySQL on an EC2 instance that someone patches and backs up by hand, moved to Amazon RDS or Aurora with AWS Database Migration Service or native replication.
Between regions
A workload moved to a different AWS region, including into Canada (Central) or Canada West (Calgary) when your customers need their data kept in Canada.
Servers into managed services
Scheduled-job boxes, queue workers and file servers doing work that Lambda, SQS, ECS or S3 now does better, with less to patch and less to watch.
Off the services costing you
Third-party tools doing what AWS now does natively, and database engines past standard support, which AWS bills extra for.
An architecture you have outgrown
A design that made sense three years ago and now costs more to work around than to change. Replaced piece by piece, with the old path kept alive until the new one proves itself.
How a staged migration runs
- Scoping call and proposal. We learn what is moving and why, then send a written proposal with the deliverables, a fixed price and a delivery date.
- Inventory and plan. We map what exists and what depends on what, then split the move into stages. Each stage has a success test and a way back.
- Target environment first. The new environment is defined in Terraform before anything moves, so it can be reviewed, tested and rebuilt.
- Data kept in sync. Databases are copied, then kept in step with ongoing replication while your team tests against the new side.
- Cutover. Traffic moves in a short, planned window, following a written runbook. If a check fails, traffic goes back.
- Decommission. The old system is switched off only once the new one has proven itself. That is usually where the savings arrive.
What you get
- A migration plan: every stage, its success test and its rollback
- The target environment defined in Terraform and documented
- Data moved by replication and checked, not copied once and hoped for
- A cutover runbook your team can read and follow
- The old system retired, and its bill with it
- Documentation, so the day we stop working together costs you nothing
Modernization should pay for itself
Moving a self-managed database onto RDS removes the patching, the hand-rolled backups and the restore nobody has practised. Automated backups and point-in-time recovery come with the service, and Multi-AZ adds a standby with automatic failover. Moving servers onto managed services removes capacity that was only there just in case.
That is why this kind of work tends to save more than the quick wins in a cost audit. If you have had an audit, the migration plan starts from its findings. After the move, the reliability work gets easier too: tested restores and deploys that roll back on their own are simpler to add to a system built on managed services.
Who this is for
Teams that need to migrate to AWS and cannot afford a long outage. Teams already on AWS with a self-managed database, a server nobody wants to touch, or an architecture they have outgrown. And Canadian companies that need workloads moved into a Canadian region, often because customers ask where their data lives; see AWS security and Canadian data residency. We work with teams in Canada, the United States and Europe, remotely.
Frequently asked questions
How do you migrate a self-managed database to Amazon RDS?
Usually with AWS Database Migration Service or the replication built into the database engine: a full copy first, then ongoing replication so RDS stays in step with the old database while your team tests. The switch itself happens in a short, planned window, and the old database stays available until the new one has proven itself.
Do we have to move everything at once?
No. We plan in stages, each with its own success test and its own way back. Most systems move a piece at a time, with old and new running side by side until the new one has earned the traffic.
Should we lift and shift, or re-architect?
Usually some of each. Rehosting is quicker and lower risk for the parts that are fine as they are. Rebuilding on managed services pays back where the old setup is costly to run or to maintain. The plan says which is which, and why.
Can you move our workload into a Canadian AWS region?
Yes. AWS has two Canadian regions, Canada (Central) in Montreal and Canada West (Calgary), and moving between regions is one of the migrations we plan. More under AWS security and Canadian data residency.
Will you change our application code?
No. Application code stays with your engineers, who know it better. We handle the infrastructure, the data move and the cutover, and tell your team early about anything in the application the new setup needs changed.
How is a migration priced?
A fixed price, agreed after a scoping call and set out in a written proposal with the deliverables and a delivery date. No hourly billing, no open-ended meters.
Related services
Plan the move before you make it
Fifteen minutes on a call is enough to tell whether your migration needs outside help, and what shape it should take. If it does not, we will say so.