Run / VPS Migration
Migrations planned around the questions that matter before cutover: what is still changing, what syncs twice, and what the rollback point is.
TechSteps migrates websites, applications, databases and production services between VPS and cloud environments with verified backups, a staging rehearsal, DNS planning, a prepared rollback point and post-cutover verification. The goal is not to copy files. It is to move the workload without losing the operating knowledge that keeps it stable.
What this solves
Copying files and a database is the easy part of a migration, and it is the part most people plan for. The failures happen elsewhere: in the cron jobs nobody documented, the mail configuration that silently stops working, the queue worker that was started by hand two years ago, and the DNS TTL that means the change takes a day to propagate rather than five minutes.
The other common failure is data. A live system keeps changing while it is being copied. Orders placed during the copy, comments posted, files uploaded. Without a second synchronization pass, those are lost, and nobody notices until a customer asks where their order went.
A migration should have a rollback path decided before DNS changes, and a verification step that proves the destination is actually serving the expected workload rather than just responding.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
What is actually running on the source server, including the things nobody remembers. We look at running processes, listening sockets, cron tables, systemd units and mail configuration rather than trusting a description.
A backup is taken and restored somewhere before anything is touched. A backup that has never been restored is a hypothesis. This is also the fallback if the migration is abandoned.
The new environment is built and configured, not cloned wholesale. A migration is the best opportunity to leave behind accumulated configuration nobody can explain.
The application runs on the destination against a copy of production data, with hosts-file access, before any DNS change. Most problems surface here, where they cost nothing.
DNS TTL is reduced well before the cutover so the switch is fast and reversible. Immediately before cutover, a second sync captures everything that changed since the first copy.
DNS is switched, then we verify the destination is serving real traffic correctly. The source stays available and unchanged through the rollback window.
Once confirmed, the destination is hardened, monitoring is checked, and the arrangement is documented so the next person does not have to rediscover it.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
Traffic arrives at a server that is not fully working, and with a long TTL still cached the rollback takes hours rather than minutes.
Everything created between the copy and the cutover is lost. On a store, that means real orders. This is the most damaging and most preventable migration error.
The site loads perfectly and nothing scheduled runs. Reports stop, emails stop, queues fill up, and it is often days before anyone connects the symptoms to the migration.
The sending IP changes, SPF and DKIM no longer align, and transactional email starts going to spam. This is discovered when a customer says they never received a receipt.
The old server is cancelled the same day. When something is found missing a week later, there is nowhere to get it from.
Questions we actually get asked
For most sites, minutes rather than hours, and often none that a visitor notices. The variable is write traffic. A read-heavy site can be switched with no interruption. A busy store may need a short read-only period so the final synchronization is consistent. We tell you which case you are in during the inventory, before you commit.
We roll back to the source server, which is still running and unchanged. That is why the TTL is lowered in advance and why the source is not decommissioned immediately. The rollback path is defined and tested before the switch, not improvised during it.
Only if it is planned for. Mail is the most commonly broken part of a migration because the sending IP changes and SPF, DKIM and DMARC records have to be updated to match. If you use an external mail provider, this is straightforward. If mail is sent from the server itself, it needs deliberate attention and testing.
Sometimes, using a crawl and whatever exports are available, but the result is much weaker. Without server access we cannot see cron jobs, background workers, firewall rules or mail configuration, so we would be reconstructing rather than migrating. We will tell you exactly what we cannot verify.
Generally no, not at the same time. If the migration and a PHP or database version upgrade happen together and something breaks, you cannot tell which change caused it. Move first, confirm stability, then upgrade as a separate step with its own rollback.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.