Sorami moves servers, sites and databases to AWS, Azure or Google Cloud. The old system stays live until the new one passes your checks.
WordPress · Servers · Bare metal · VMs · Databases · Kubernetes · Email and DNS
Sorami plans a cloud migration around the rollback, not the move. We map every dependency and replicate data while the old system keeps serving. We rehearse the cutover on a copy, then switch in an agreed window. The old environment stays ready to take traffic back until the new one passes the checks you approved.
The copy is rarely the problem. The surprises are in what nobody listed.
Each has its own failure point. Here is how we handle each one.
We move the files, the database and the media library together, then rewrite the URLs that point at the old host. Plugins and PHP versions are checked on the new stack before any DNS change.
A whole server is rarely one thing. We inventory what runs on it before we copy anything. That means services and cron jobs, local files and certificates, and the ports other systems call.
Hardware in a rack has constraints a cloud does not: fixed disks, local RAID and licences tied to a physical host. We size the target from measured load rather than the spec sheet.
VMs from VMware or another hypervisor can usually be replicated block by block. The work is in drivers, boot settings and the network design the VMs expected.
The database decides the downtime window, so it gets planned first. We pick between a dump and restore, native replication or a managed migration service based on size and write rate.
Moving containers is mostly moving everything around them. Images and secrets, volumes and ingress, and DNS all have to arrive together. Otherwise the pods start and nothing answers.
DNS is the switch the whole migration flips, and email is where a mistake is noticed first. We lower record TTLs days ahead so the change takes effect quickly and can be reversed quickly.
Data syncs while you keep serving, so the switch itself is short.
Every workload, what it talks to and who owns it. Nothing moves until the map is agreed.
Accounts, network and identity on the target, plus the order of moves and the cutover window.
Data syncs to the target while the old system keeps serving. We rehearse the cutover on a copy first.
The switch happens in an agreed window. The old environment stays live and ready to take traffic back.
Checks against the agreed list, then runbooks and access handed to your engineers.
Zero downtime is possible for some stateless web workloads with load-balanced cutover. We only promise it where the plan shows how. Everywhere else the plan states the expected window in minutes, and we rehearse it first.
A deeper look after the move is a cloud security review.
Copying servers at their old size is the most common way a move costs more.
If the bill already moved after an earlier migration, start with a cloud cost review.
Sometimes the right answer is to fix what you have.
If the current setup holds, we say so in writing. Sorami is not an AWS, Microsoft or Google partner and takes no reseller margin, so the target is chosen on fit and running cost. When the design itself is in question, an architecture review comes first. Platform detail is on the AWS, Azure and Google Cloud pages.
It depends on the database write rate and how the application handles a switch. Most web workloads can cut over in minutes using replication and lowered DNS TTLs. We state the expected window in the plan before you approve it, and we rehearse it first.
Yes. Sorami moves the files, database and media together and tests the site on AWS before any DNS change. Lightsail, EC2 or a container setup are all options, chosen on traffic and how much you want to manage.
We roll back. The old environment stays running until the new one passes the agreed checks. The rollback step is written into the plan with the trigger that calls it.
No. Sorami is not an AWS, Microsoft or Google partner and takes no reseller margin. The target platform is recommended on fit and running cost, and we say so in writing when staying put is the better answer.
It can, if servers are copied at their old size and left running. We size from measured load, set budgets and alerts on day one, and list the savings still open after cutover.
Yes, scoped and time-limited. Access is agreed in writing, uses named accounts with least privilege, and is removed at handover. Please do not send credentials through the form.
Yes. Moves between AWS, Azure, Google Cloud and providers such as DigitalOcean or Hetzner follow the same method. The managed services differ, so the plan maps each one to its closest match on the target.
A rough list of what runs where, who owns the domain and DNS, and any deadline such as a contract or hardware end date. The form above is enough to start.
Send what runs where and any deadline. We reply within one business day with a time for a scoping call.
Last reviewed: