Site Migration and Cost
Moving a site to a new host: the WordPress migration workflow, DNS propagation downtime, managed vs DIY migration, and the total-cost-of-ownership calculation.
Site migration is the hosting decision that gets postponed until the reason to do it is urgent โ a shared host that keeps throwing 503 errors, a renewal invoice that doesn’t match what was quoted, or a performance audit that shows the origin server is the bottleneck. Urgent migrations are avoidable with a clear understanding of what migration involves, how long it takes, and what it actually costs. Most migrations are less technically demanding than they appear and more expensive in time than they appear.
The WordPress migration process has three stages: copying files and database, updating configuration, and switching DNS. The files and database copy is usually the longest step for large sites โ a site with a 2GB database and 5GB of media files will take twenty minutes to an hour depending on server speed and network throughput. The standard tool is a migration plugin: All-in-One WP Migration, WP Migrate DB Pro, and Duplicator are the commonly used options, and most managed hosts have their own migration tool that simplifies the process. Kinsta provides a free WordPress migration service performed by their team โ for complex sites with custom configurations, this is worth taking. Cloudways has its own migration plugin (the Cloudways Migrator) that handles the transfer with a wizard interface and is straightforward for most WordPress installs. Hostinger includes a free migration service for plans at the higher tier, which is useful for users migrating from a host with an awkward control panel.
The DNS cutover is where migration gets complicated and where downtime risk is concentrated. DNS propagation โ the process of updated nameserver records spreading across the global DNS system โ takes between minutes and 48 hours, with the actual time determined by the Time to Live (TTL) settings on your current DNS records. The risk window is the propagation period: some visitors are being sent to the old server, some to the new one, and form submissions, orders, and content updates made during this window may end up on the server you are about to shut down. The mitigation is simple: before you begin the migration, reduce the TTL on your DNS records to 300 seconds (five minutes). This requires advance planning โ the change takes effect after the current TTL expires, so you need to make this change at least 24โ48 hours before you plan to migrate. With a 300-second TTL, propagation after DNS cutover completes in under ten minutes rather than up to 48 hours, and the data-loss risk window is correspondingly smaller.
The total-cost-of-ownership calculation for a migration is the sum of migration cost, re-configuration cost (SSL certificates, email DNS records, plugin settings that reference the old server’s absolute paths), and any downtime cost. The direct migration cost is often zero if you use a plugin or a host-provided migration tool; it is $100โ200 if you pay a developer for a straightforward WordPress migration; it is higher if the site has complex custom code, non-standard configuration, or a large media library. The ongoing savings justify migration when the new host’s monthly pricing, at equivalent or better performance, reduces the running cost by enough to repay the migration effort within a reasonable period.
The scenario where migration cost escalates unexpectedly is absolute URLs stored in the database. WordPress databases frequently contain fully-qualified URLs (including the domain) in post content, options tables, and serialised data. Migrating to a new domain โ or even just from HTTP to HTTPS โ without running a search-and-replace on the database produces a site with broken internal links, missing images, and layout failures. The standard fix is WP-CLI’s wp search-replace command or a plugin like Better Search Replace. Running this as a post-migration step is not optional; overlooking it is the most common cause of a migration that looked successful but produced a broken site.
When to pick what: use Cloudways for migrations where you want control over the destination infrastructure and have the technical capability to manage a staged migration with your own tooling โ the Cloudways Migrator plugin handles most WordPress moves cleanly and the platform gives you server-level access to verify the result. Use Kinsta’s free migration service for complex sites, high-traffic production environments, or any migration where the cost of a mistake is high โ you are paying for expert execution, not just server capacity. Use Hostinger as the destination when migration is part of a cost-reduction move and you are comfortable with a simpler managed environment; their migration assistance reduces the effort for users coming from technically awkward origins.