Cloud migration consultant for near-zero-downtime moves to AWS and GCP
As a cloud migration consultant I plan and run moves to AWS or Google Cloud so that customers don’t notice. Applications move behind a load balancer you can shift gradually; databases move by replication, not by a weekend outage. I do the hands-on work with your team rather than handing over a slide deck.
I’ve built and run production systems on both clouds: AWS at WixelHQ, the studio I co-founded and sold after 200+ projects, and Google Cloud for Indiemaker, which runs at 99.9% uptime. Pepkor NexTech worked with me across software engineering, solutions architecture and cloud infrastructure.
Common triggers for a migration
- An operating system at end of life. CentOS Linux 8 ended in December 2021 and CentOS 7 in June 2024. Servers still on either get no updates, and the replacement (Rocky Linux, AlmaLinux, RHEL or Ubuntu LTS) is a good moment to stop hand-managing servers altogether.
- A data center or colocation contract coming up for renewal.
- Leaving a PaaS that has become too expensive or too limiting – see Heroku alternatives.
- Compliance or data residency requirements from enterprise customers.
- Consolidation after an acquisition, when two companies run on two clouds.
Choosing how much to change
Every workload gets one of a few treatments: rehost it as-is (lift and shift), replatform it onto managed services (RDS or Cloud SQL instead of a self-run database, containers instead of VMs), refactor it, replace it with SaaS, or retire it.
My bias is to replatform the stateful parts and rehost the rest. Managed databases remove backups, patching and failover from your on-call list, which is usually the biggest win. Large refactors during a migration double the risk – do them afterwards, once you’re stable.
Database migration services, done properly
The database is where migrations go wrong. The approach depends on size, engine and how much downtime you can tolerate:
- Small databases: dump and restore in a rehearsed maintenance window. Boring and dependable.
- Same engine, larger data: native replication. Postgres logical replication (publication and subscription) or MySQL binlog replication keeps the target in sync until you promote it.
- Managed tooling: AWS Database Migration Service or Google Cloud’s Database Migration Service handle full load plus change data capture for common engines. Test them on a copy – they have edge cases with large objects, sequences and certain data types.
- Changing engines (MySQL to Postgres, for example): CDC with Debezium or DMS, plus schema translation. I cover this in MySQL to PostgreSQL migration.
Before cutover I compare row counts and checksums per table, reset sequences, and check that replication lag is near zero.
The cutover plan
- Infrastructure as code first. Terraform or OpenTofu for networks, IAM, databases and compute, so the target environment is reviewable and reproducible.
- Connect the old and new environments via VPN or interconnect so the new app tier can talk to the old database during transition.
- Move stateless services first and shift traffic in steps with weighted DNS or load balancer rules.
- Rehearse the database switch on a copy until it’s routine, with a written runbook and timings.
- Cut over at the quietest hour: stop writes briefly, confirm replication has caught up, promote the target, repoint the app, run smoke tests.
- Keep a rollback path – reverse replication or the old primary held read-only – until you’re confident.
AWS consultant or Google Cloud consultant?
Both clouds are good. AWS has the widest service catalog and the largest hiring pool. Google Cloud is simpler to operate for many teams, with strong managed Kubernetes and serverless containers in Cloud Run. Pick the one your team already knows, unless a customer or a specific managed service decides it for you.
After the move, the next question is usually cost. That’s its own job: AWS cost optimization.
Questions
What does a cloud migration consultant do?
A cloud migration consultant assesses what you run, decides how each workload should move, designs the target environment and plans the cutover. A hands-on one also writes the infrastructure code, sets up replication and runs the migration with your team rather than just advising.
Can a database migration be done with zero downtime?
Close to it. With logical replication or change data capture the target stays in sync, and the final switch needs only a few seconds to a minute of paused writes. True zero downtime requires dual writes, which add complexity most teams don’t need.
CentOS is end of life – what should we migrate to?
Rocky Linux and AlmaLinux are the closest drop-in replacements for CentOS. If you’re rebuilding anyway, consider containers on managed services so the operating system becomes the cloud provider’s problem. Either way, don’t keep running unpatched servers.
How long does a cloud migration take?
A single application with one database can move in weeks. Larger estates take months, mostly spent on inventory, dependencies and rehearsals. The two-week sprint produces a concrete plan, and the aim is to move the first workload inside it.
Planning a move to AWS or GCP?
Tell me what you’re running and why it needs to move. In a two-week sprint I’ll map the migration and move the first piece.
GMT+2 · Full EU overlap · US East mornings