Run / WordPress to VPS Migration
WordPress-specific migration depth: TTL planning, the second sync for orders and comments, cron, mail and post-cutover verification.
TechSteps moves WordPress and WooCommerce sites from shared hosting or another server onto a VPS, with the WordPress-specific parts handled properly: the serialized data in the database, the second content sync for posts and orders placed mid-migration, cron, transactional mail, and a rollback path held open after DNS changes.
What this solves
WordPress migrations look simple and have a set of specific traps that generic migration advice misses. The database contains serialized data where a naive find-and-replace on the site URL corrupts the serialization and breaks widgets, theme options and plugin settings in ways that are not immediately obvious.
WordPress also has its own scheduled task system, which depends on traffic unless it has been switched to a real system cron. Moving a site without converting that leaves scheduled posts, backups and order processing running unpredictably or not at all.
Then there is the content that arrives during the migration. On a store, an order placed between the database copy and the DNS switch exists only on the old server. Without a second synchronization, it is gone.
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
Plugin list, theme, PHP version, database size, upload directory size, cron behavior and mail path. This determines whether the destination needs to be sized differently from what a plan comparison would suggest.
PHP workers, database configuration and caching sized for the real site rather than a default. A VPS with the wrong worker configuration can be slower than the shared host it replaced.
Files and database copied to the destination, URL replacement done in a serialization-safe way, and the site tested through a hosts file entry so it is never publicly indexed on a temporary domain.
Admin login, checkout with a real payment method in test mode, contact form email, scheduled publishing, and search. These are the areas where a migration silently fails.
TTL reduced at least a day ahead. For stores, we agree whether a short read-only window is acceptable or whether we reconcile orders after the switch.
Everything created since the first copy is synchronized, then DNS is changed. The old server stays running and untouched.
Confirm real traffic is being served correctly, check mail deliverability from the new IP, then apply hardening, backups and monitoring.
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.
A plain SQL replace on the site URL breaks serialized strings, because the stored length no longer matches. Theme options and plugin settings quietly stop working, and the cause is not obvious.
WordPress cron fires on page loads. On a low-traffic site scheduled tasks run late or not at all. It should be disabled and replaced with a real system cron entry during migration.
Between the database copy and the DNS switch, orders continue on the old server. Without a second sync those orders do not exist on the new one, and the customer has paid.
A new server usually means new caching. Applied without exclusions, customers see stale carts or, far worse, someone else's session.
The new IP is not covered by SPF, so receipts and password resets go to spam. Nothing errors. You find out from a customer complaint.
Questions we actually get asked
For a small, simple site, often yes. They handle the common case competently. They tend to struggle with large databases, large upload directories, sites with must-use plugins or custom drop-ins, and anything needing a second synchronization. They also do not configure the destination server, which is usually where the performance benefit of moving actually comes from.
It can be substantially faster, and only if the VPS is configured properly. An unconfigured VPS with default PHP settings and no object cache can be slower than good shared hosting. The gain comes from tuning PHP workers, the database and caching for your specific site, which is the part we do.
They are handled explicitly. Either we agree a short read-only window so no orders are placed during the final sync, or we synchronize orders after the cutover and reconcile them. Which approach fits depends on your order volume. What we do not do is hope the gap is empty.
Usually a few things. WP-Cron should be disabled in favour of system cron. Caching plugins often need reconfiguring for the new server-level cache. If the site was using a host-specific plugin, that comes out. We list these before the migration so nothing is a surprise.
Someone has to. A VPS gives you control and hands you responsibility for patching, monitoring and backups. We can manage it under an ongoing arrangement, or hand it over documented if you have someone. What we will flag is when nobody is going to own it, because an unmaintained VPS is worse than the shared host you left.
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.