Cloud
Migration

We inventory what you run, what it talks to and what would break if it moved: services, cron jobs, file uploads, third-party callbacks, hard-coded addresses and the DNS records nobody remembers creating. The output is a dependency map plus a short, blunt list of the things that will actually make this migration difficult.

We design the destination — managed database, application hosting, object storage, background jobs — and price it against your current bill, including the items people forget: egress, backups, log retention and non-production environments. Cloud is not automatically cheaper, and if the model says your current setup wins on cost, you get the numbers rather than a sales answer.

Rehost is fastest and changes least; replatform swaps self-managed components such as your own database server for managed equivalents; refactor reshapes parts of the application to suit the platform. We decide per workload rather than for the estate as a whole, because paying for a refactor on a stable back-office tool is how migration budgets disappear.

Schema and data move into the target with repeatable scripts — Prisma migrations where the stack allows — and we run the whole load against a copy first to measure how long the real cut will take. The rollback is written, timed and tested before a date is agreed, because a plan nobody has rehearsed is not a plan.

We lower DNS TTLs in advance, issue and validate certificates on the new platform, run both environments in parallel where the data model allows, and switch traffic inside a defined window with writes frozen only for as long as strictly necessary. Sessions, webhooks, scheduled jobs and outbound mail are re-pointed as part of the same checklist rather than discovered afterwards.

For the first weeks we watch error rates, latency, database connections and spend, then right-size instances and caching once real traffic has shown what the workload needs. We restore from a backup to prove it works, and hand over runbooks for deploys, rollbacks and incidents so your team can operate the platform without us.