The most dangerous part of a website hosting migration is often the moment when everyone assumes the hard work is finished.
The files have been copied. The database is on the new server. The new website looks fine when someone opens it directly. Then DNS changes, visitors begin arriving at the new host, and an overlooked detail appears: a form stops sending, an SSL certificate is missing, a payment integration still points to the old server, or recent orders never made it across.
A hosting migration is not simply a file transfer. It is a controlled change to the infrastructure behind a business website. The safest migrations treat the old environment as live until the new one has been tested and the DNS transition has been completed.
For Canadian businesses, that matters whether the website is a small brochure site, a WordPress installation, an online store or a custom application. If you are evaluating the infrastructure itself, HB Technology Solutions provides Domain & Cloud Hosting with hosting, monitoring, security and technical support.
Start with an inventory, not the migration button
Before moving anything, document what the current hosting environment actually does.
It sounds basic. It is also where many migrations go wrong.
Make a list of the website files, databases, domains and subdomains. Then look beyond the obvious. Does the website send email through the server? Are there scheduled cron jobs? Does an application connect to an external API? Are customer uploads stored locally? Is there a staging site? Does DNS contain records for Microsoft 365, Google Workspace, a CDN, verification services or third-party payment systems?
For a WordPress website, check the active theme, plugins, PHP version, database version, media library, scheduled tasks and any custom code. A custom application needs an even closer look at environment variables, queues, workers, storage and deployment dependencies.
This inventory becomes the migration checklist. Without it, you are relying on memory.
1. Lower the DNS TTL before the move
DNS changes are not necessarily visible everywhere at the same moment. The time involved depends partly on DNS caching and the TTL, or time to live, configured for the record.
If the migration is planned several days ahead, reducing the relevant DNS TTL can help make the eventual change easier to manage. The exact value depends on the DNS provider and migration plan; the important point is to make the change before the cutover rather than minutes before it.
Do not confuse TTL with a guarantee that every visitor will immediately reach the new server. DNS resolvers and local systems can behave differently, and other records may still have their own caching behaviour.
2. Take a backup you can actually restore
Before copying anything, create a fresh backup of the website files and database. Keep a separate copy outside the environment you are migrating.
Then verify it.
A backup file that exists is not automatically a usable backup. Check that the archive can be opened, the database can be restored and important uploads are present. If the website processes orders, registrations or enquiries, identify the data that must not be lost during the transition.
For more guidance on the infrastructure surrounding backups, access control and hosting security, see cloud hosting security mistakes Canadian businesses should avoid.
3. Build the new environment before changing DNS
The new server should be ready while the existing website remains live.
Install the required operating system components, web server, database engine, PHP or application runtime, SSL configuration and supporting services. Match the production environment closely enough that the application behaves as expected, while taking the opportunity to remove obsolete software and unnecessary services.
This is also a good time to review resource requirements. A website that has outgrown shared hosting may need different CPU, memory, storage or database resources on the new platform. A high-traffic application may need load balancing, caching or a more deliberate deployment architecture rather than simply a larger server.
If the business needs ongoing monitoring and infrastructure administration rather than a one-time server move, Managed IT Services can be considered as part of the wider hosting strategy.
4. Copy the website and database, then test the copy privately
Move the files and database to the new environment before the DNS cutover.
Do not judge the migration by the homepage alone. Test the parts visitors and staff actually use: navigation, contact forms, login, search, media, downloads, account areas, checkout, confirmation emails and administrative functions.
Check the browser console and server logs for errors that a visual inspection will miss.
For websites where organic search matters, also inspect redirects, canonical URLs, robots.txt, XML sitemaps and important metadata. A technically successful migration can still create an SEO problem if URLs or crawl controls change unexpectedly. HB Technology Solutions covers this area through SEO & Performance Optimization.
5. Do not forget email
Email is one of the easiest things to overlook because it may not live on the same server as the website.
Review the DNS records before making changes. In particular, identify MX records and any SPF, DKIM and DMARC records associated with the business email service. If the website sends transactional messages, confirm whether those messages use the web server, an SMTP provider or a separate email platform.
A website migration should not accidentally become an email outage.
6. Install and verify SSL before the DNS switch
HTTPS needs to work on the new environment before real traffic arrives.
Test the primary domain, www version if applicable, important subdomains and any application-specific endpoints. Confirm that HTTP redirects to HTTPS correctly and that the certificate covers the hostnames visitors actually use.
Do not wait until after the DNS change to discover that the new server has a certificate problem. Visitors should be able to connect securely from the first request.
7. Check application configuration and environment variables
Moving files does not necessarily move the configuration that makes an application work.
Database credentials, API keys, mail settings, storage paths, application URLs, cache settings and third-party service credentials may all change between environments. A copied configuration file can also contain references to the old server.
For a custom web application, check background workers, scheduled jobs, queues and external integrations separately. A page can load correctly while a queue worker is still pointing at the previous database.
Businesses running larger or more specialized applications may benefit from a migration plan that accounts for the full application architecture. Custom Web Application Development is relevant when the hosting move is part of a broader application rebuild or infrastructure change.
8. Freeze changes before the final database sync
This is where the migration becomes a controlled cutover rather than two copies of a website drifting apart.
If the site is mostly static, the final synchronization may be simple. An online store, membership website or application that receives continuous transactions is different. Orders, registrations, comments and customer records can continue changing while the migration is underway.
For those sites, define a short change-freeze window or use a migration method that keeps the destination synchronized until the final switch. The exact approach depends on the application and database architecture.
Never assume the first database copy is the final database copy if users are still writing new data to production.
9. Change DNS only after the destination passes testing
Once the new environment is ready, perform the DNS change according to the migration plan.
Record the old DNS values before changing anything. Keep the previous hosting environment available while DNS propagation takes place and avoid cancelling the old service immediately.
During the transition, monitor requests reaching the new environment and watch for errors. Test the site from more than one network or location if practical. You are looking for the things a staging test cannot reveal: unexpected redirects, cached content, certificate issues, DNS mistakes or services that were missed in the inventory.
10. Watch the site after the cutover
The migration is not finished when DNS changes successfully.
For the first hours and days, monitor server resources, application errors, uptime, database activity and important user actions. Check contact forms and transactional email. For e-commerce sites, verify orders and payment processing. For lead-generation websites, make sure enquiries are arriving where they should.
Search performance should also be watched after a significant migration. If URLs, redirects or site architecture changed, use search monitoring and analytics to identify unexpected changes.
If the website is being migrated because the old platform has become slow or difficult to maintain, it is useful to establish a baseline before the move. The existing comparison of cloud hosting and traditional hosting for Canadian businesses provides useful context when assessing the infrastructure decision itself.
11. Keep the old host available for a while
Deleting the old server immediately creates unnecessary pressure.
Keep it available for an appropriate period while confirming that the new environment is receiving traffic and all critical functions are working. The right retention period depends on the website, DNS setup and business risk; there is no universal number of hours or days that fits every migration.
Once the new environment has been verified, remove obsolete credentials and shut down the old service deliberately. Before doing so, confirm that no DNS record, integration, scheduled task or third-party system still depends on it.
A practical pre-launch checklist
Before changing DNS, someone should be able to answer yes to the following:
Current website files and databases have been backed up.
The backups have been checked and can be restored.
All domains and DNS records have been inventoried.
The new server has the required software and resources.
The migrated database and files have been tested.
Forms, logins, search, uploads and important application functions work.
SSL certificates are installed and HTTPS works correctly.
Email-related DNS records have been reviewed.
API keys, database credentials and environment variables have been updated.
Scheduled jobs, queues and background processes have been checked.
Redirects, canonical URLs, robots.txt and XML sitemaps have been reviewed.
DNS TTL has been considered as part of the migration plan.
The final synchronization or content freeze process is defined.
The old hosting environment will remain available during the transition.
Someone is responsible for monitoring the website after the DNS change.
What “without downtime” should really mean
There is a useful distinction between zero downtime and a migration that users never notice.
A website can remain continuously available while DNS changes, but that does not mean every component changes simultaneously. Some users may reach the old server while others reach the new one. That is why data synchronization, application compatibility and keeping both environments functional during the transition matter so much.
The goal is not to make the migration look dramatic. It is to make the change boring.
For many Canadian businesses, the safest approach is to build the new hosting environment first, test it thoroughly, synchronize the data at the right point, switch DNS, monitor the result and only then retire the old infrastructure. That sequence reduces the number of things that can go wrong at the exact moment customers are trying to use the website.
If you are planning a hosting migration and want help reviewing the infrastructure, DNS, security and deployment requirements, Request a Free Project Proposal from HB Technology Solutions.
