Moving off on-premise, or back onto it, without a weekend everybody remembers.
Between cloud providers, out of one entirely, or onto hardware you own again. The account, the domains and the keys are yours from day one, opened in your name if they don't exist yet, not handed over at the end if the project goes well.
What this is
Almost nobody has a complete list of what's actually running before a migration starts. There's the service on the ticket, and then there's the cron job someone set up three years ago, the VPN tunnel to a partner's network, and a database with a name that stopped meaning anything after the person who named it left. The first real deliverable of a migration is that list, written down, because a migration plan built on the documented version of an environment breaks on the parts nobody documented.
Once the inventory exists, the schedule gets set by whatever's stateful. Web and application tiers that don't hold data of their own move in an afternoon: stand up the new copy, point it at the same backing services, tear down the old one. A database does not work that way. We keep the source and target in sync with replication or change-data-capture right up to the last possible moment, then take a short write-freeze to flip traffic over, rather than a dump-and-restore that holds the whole system offline for however long the export takes. The old environment stays live and in sync for an agreed window after cutover specifically so traffic can go back to it if the new one has a problem nobody caught in testing.
The direction isn't always outward. A workload that runs at a steady, predictable load stops being cheap on infrastructure billed for elasticity it never uses, and moving it back onto owned hardware is a legitimate outcome of the same analysis that sometimes says move to the cloud. We size the target to the actual traffic pattern, not to whichever direction happens to be fashionable that year.
The account itself is the part most migrations get wrong quietly. We open or use a cloud account in the client's name, billing and admin included, and configure our own access as a time-limited, least-privilege role that gets revoked at close. Domains stay in a registrar the client controls and certificates get issued to accounts the client owns. An agency that builds the new environment inside its own account has built you a dependency, not a migration, and we don't do that.
What you get
The inventory
Every service, dependency and credential actually discovered running, not just the ones that were already on a diagram.
A cutover plan
The window, the rollback trigger and who calls it, decided in writing before anything moves, not argued live.
Data migration
Replication or change-data-capture keeping source and target in sync, verified with a row-count or checksum comparison before cutover, not assumed.
DNS and TLS handled
TTLs lowered ahead of the window, certificates reissued in the client-owned account, records cut over on schedule.
A client-owned account
Billing, admin and IAM configured with least-privilege roles, handed to you with our temporary access revoked at close.
A tested rollback runbook
The exact steps to point traffic back at the old environment, proven before the cutover, not written and hoped for.
A real cost comparison
What the new environment costs at your actual traffic, checked against what was assumed at the start.
Documentation
The new environment's architecture and access, written for whoever inherits it, including if that's your own team.
When this fits, and when it does not
A good fit
- You're opening a new cloud account, or you have one that needs to actually run the workload rather than sit as a placeholder next to the old servers.
- The risk is the database, not the web tier: something stateful has to move without a weekend of downtime nobody signed off on.
- Your current cloud bill has stopped matching a steady, predictable load, and moving back onto owned hardware, or to a smaller footprint, is genuinely on the table.
- You've been left holding a dependency by an agency that built the last environment inside its own account, and you want this one to end differently.
- You need the target environment documented well enough that the next person, whoever that turns out to be, isn't starting from a blank screen.
Not a good fit
- What you actually need is faster, more frequent deploys on infrastructure you already have and aren't moving anywhere. That's DevOps and CI/CD, not a migration.
- What worries you is losing data, not where it's hosted. That's backup and disaster recovery, and it's worth designing for the new environment once it exists rather than folded into the move itself.
- You want to know whether the environment can be broken into. That's penetration testing and security review, best run once the migration has landed and settled, not mid-cutover.
- It's one static site or a single WordPress install on shared hosting. A hosting reseller will move that in an afternoon for a fraction of the cost; this is more process than that target needs.
- You need it done by Friday with no cutover window and no rollback plan. That's the plan that produces the weekend everybody remembers, and we'll say so rather than run it that way.
How it runs
- 01
Inventory
Every service, dependency and forgotten cron job, written down and confirmed, before anything gets a number attached to it.
- 02
Plan the cutover
The window, the rollback trigger and who's authorized to call it, agreed in advance rather than decided live.
- 03
Move the stateless pieces
Web and application tiers, proven running in the new environment while the old one still serves production traffic.
- 04
Migrate the state
Replicate the database to the target, verify it matches, then a short freeze to flip traffic over.
- 05
Hand over
Client-owned account, access and documentation delivered, and our temporary credentials revoked.
Questions we get
How much downtime should we expect?
Close to none for the stateless tiers. For anything with a database, we aim for a freeze window measured in minutes, using replication to keep the target current until the last moment rather than a multi-hour dump-and-restore. You get that number in the cutover plan before the window, not after.
Do you only move workloads off on-premise, or between clouds too?
Both directions, plus the reverse. AWS to Azure, on-premise to GCP, cloud back onto hardware you own. The mechanics, inventory, replication, cutover, tested rollback, are the same regardless of what sits on either end.
Who actually owns the new environment afterward?
You do, starting from the account level. We open or use your cloud account, your domain registrar and your billing. Our access is scoped to the migration and revoked when it's finished, not kept on as a standing dependency.
What happens if something goes wrong mid-cutover?
The old environment stays live and in sync for an agreed window after cutover, specifically so traffic can be pointed back at it. That window and the trigger for using it are decided before we start, not argued about while something is down.
Have an environment that needs to move?
Tell us what's running today and where it needs to end up. An engineer reads it and gives you a straight answer on the cutover, the risk, and the account it should live in.