After a website migration, the new site can appear live in some places within minutes, while other visitors may still reach the old version for several hours. In most cases, a migrated website is fully live everywhere only after DNS propagation has completed and cached records have expired. For European hosting environments, this usually happens within a few hours, but in some networks it can take up to 24–48 hours.
The exact timing depends on the DNS record TTL, the speed of ISP cache updates, browser and device caching, and whether the switch was made correctly in your control panel or DNS provider. If the migration was planned well, the visible downtime should be minimal, and users should gradually move from the old server to the new one as caches refresh.
How long DNS propagation usually takes after a website migration
DNS propagation is the process by which internet resolvers update stored DNS information after you change your records. When you point a domain to a new hosting platform, the change does not reach every visitor instantly. Instead, it spreads across DNS resolvers, ISP caches, mobile networks, browsers, and other systems.
Typical timelines are:
- 5–60 minutes: Many users start seeing the new site quickly if the TTL was low and caches refresh fast.
- 1–6 hours: A common window for most visitors to reach the migrated website.
- 24 hours: Often enough for most DNS changes to settle globally.
- 24–48 hours: Possible in slower networks or when previous TTL values were high.
If your website uses managed hosting, Plesk, or another control panel, the migration itself may be complete long before all traffic has switched over. That is normal. The important part is keeping both the old and new environments stable during the transition period.
What affects when a migrated website is live everywhere
1. DNS TTL values
TTL, or Time To Live, tells DNS resolvers how long they may cache a record before checking for updates. A long TTL can make a migration safer during normal operation, but slower when you need to switch a website to new hosting. If your A record, AAAA record, or CNAME had a TTL of several hours or a full day, some users may continue seeing the old destination until the cache expires.
2. Resolver and ISP caching
Some internet providers refresh DNS quickly; others hold records longer than expected. Even if you changed the domain correctly in your hosting control panel, the user’s ISP may still remember the old record. This is one of the main reasons a migrated website can appear live for you, but not for everyone else at the same time.
3. Browser, OS, and device caches
Browsers and operating systems may cache DNS responses temporarily. Mobile devices on private or carrier networks can also behave differently. If you test the site from the same device repeatedly, you may see the same result even after the live cutover has finished.
4. IPv4 and IPv6 configuration
If your domain uses both A and AAAA records, both must point to the correct target. A common issue after migration is updating the IPv4 address but forgetting the IPv6 address. In that case, some users may still reach the old server or encounter inconsistent results depending on their network stack.
5. DNS zone transfer or secondary DNS delays
If you use secondary DNS or external DNS services, updates may need to synchronize between multiple nameservers. This can add a small delay, especially in EU hosting setups where DNS may be distributed across separate providers for resilience.
6. CDN and reverse proxy caching
If a CDN, WAF, or reverse proxy sits in front of the website, visitors may continue receiving cached content even after DNS has changed. In that case, the domain may already point to the new hosting platform, but the visible content may still come from an edge cache until it expires or is purged.
What happens during the live cutover
During the cutover, the old hosting environment and the new one can both receive traffic for a period of time. This is why migration planning matters. A safe cutover usually involves lowering TTL in advance, copying the final data, switching DNS records, and checking the site on both ends until all traffic has moved.
In a Plesk or managed hosting environment, the process often looks like this:
- Prepare the new server and test the site on a temporary address or hosts-file override.
- Lower the TTL of the affected DNS records before the migration.
- Perform the final database and file sync.
- Update the DNS A, AAAA, or CNAME records to the new destination.
- Monitor propagation and verify that mail, SSL, and application settings are working.
For most websites, the site is considered live everywhere only when the majority of public resolvers have switched and you no longer see meaningful traffic going to the previous host.
How to check whether the migrated website is live everywhere
You do not need to guess. There are practical ways to confirm the cutover status.
Check the DNS record from multiple locations
Use DNS lookup tools or your hosting panel’s DNS diagnostics to verify that the domain resolves to the new IP address or hostname. Compare results from several regions if possible, especially if your audience is spread across Europe.
Test with different networks
Open the site on:
- your office or home connection
- a mobile connection
- an incognito/private browser window
- a different device
If the domain resolves to the new server in all of these tests, propagation is likely close to complete. If some devices still see the old site, that usually means a cache has not expired yet.
Check server logs
Access logs on the old and new servers can show where traffic is still going. If requests keep arriving at the old server after the DNS switch, propagation is still ongoing. When old-server traffic drops to a small number or stops, the cutover is nearly complete.
Verify the SSL certificate
If the new host uses a different certificate or a new certificate was issued after migration, make sure HTTPS works correctly. A website may resolve correctly but still fail for some users if the certificate does not match the domain or if the certificate chain is incomplete.
How to reduce the time until the site is live everywhere
The fastest way to improve cutover speed is to prepare DNS before the migration begins.
Lower the TTL ahead of time
Set a shorter TTL 24–48 hours before moving the website. This gives existing caches time to age out under the new lower value before the actual switch. A TTL of 300 seconds or 600 seconds is common for migration windows, though the best value depends on your setup.
Keep the old hosting active briefly
Do not cancel the previous hosting environment immediately. Keep it available long enough to serve any visitors whose DNS still points there. This avoids downtime while propagation finishes.
Use a synchronized database and file update
If the site is dynamic, update the database content and uploaded files as close to the DNS change as possible. This helps prevent users from seeing stale content on one server and fresh content on the other.
Ensure nameservers are correct
If you moved the DNS zone to a new provider, confirm that the domain registrar points to the right authoritative nameservers. A wrong nameserver setting can delay the cutover much more than a simple record update.
Clear CDN and application caches
If you use caching layers, purge them after the migration. That includes CDN cache, object cache, page cache, and any application-level cache. This helps users see the current site faster once DNS has switched.
Common reasons a migrated website is not live everywhere yet
If the site works for some visitors but not others, one of these issues is usually responsible:
- the TTL was not lowered before the migration
- an old A or AAAA record still exists
- the www and non-www versions point to different servers
- the nameservers were not updated at the registrar
- a CDN is still serving cached content
- browser cache or local DNS cache needs time to expire
- the new server is missing a virtual host or domain alias in Plesk
- the SSL certificate is not installed correctly on the new platform
If you host multiple sites on one server, also check that the domain mapping is correct in the control panel. In Plesk, for example, the domain should point to the intended subscription or webspace, and the document root should match the migrated application files.
Post-migration checks after the DNS switch
Once the new DNS settings are in place, complete a short verification checklist.
- Confirm the domain resolves to the new IP address.
- Check both HTTP and HTTPS access.
- Test the homepage and key inner pages.
- Submit a test form if the site has one.
- Verify login, checkout, search, or other critical functions.
- Make sure email services are not affected by the DNS change.
- Review server error logs for missing files or configuration issues.
For ecommerce sites, test order placement and payment callbacks carefully. For content-heavy sites, verify that images, CSS, JavaScript, and rewrite rules are loading from the new environment.
How long until search engines see the new website?
Search engines do not “wait for DNS” in the same way users do, but they do need time to crawl the updated site, follow redirects, and update their indexes. If the content moved to a new location, make sure:
- the old URLs return the correct 301 redirects if needed
- the canonical tags are correct
- the sitemap is updated
- the new host returns stable, fast responses
In practice, search engines may reflect the migration within days, while users usually see the new hosting destination much sooner. Keep the old site available until crawling activity has stabilized, especially if the migration includes URL changes.
How to tell if the migration is finished
A migrated website is effectively live everywhere when all of the following are true:
- DNS lookups consistently return the new server
- old-server traffic has dropped to near zero
- the website works on multiple networks and devices
- HTTPS is valid and no certificate warnings appear
- application data is current and no stale cache remains
If these checks pass, the cutover can be considered complete. In many hosting migrations, this happens within the same day, but you should still monitor the site for at least 24 hours after the switch.
FAQ
How long does it take for a migrated website to go live everywhere?
Usually a few hours, but it can take up to 24–48 hours depending on TTL values, DNS caching, and network conditions. In well-prepared migrations, most users see the new site within the first few hours.
Why do I see the new site but other people still see the old one?
Different resolvers and devices refresh DNS at different times. You may have a fresh cache while someone else’s ISP or browser still holds the old record.
Can I speed up DNS propagation?
You cannot force every network to refresh instantly, but you can lower TTL in advance, keep the old host active, and clear CDN or application caches. These steps reduce the practical delay.
Does changing hosting always cause downtime?
No. With proper planning, downtime can be minimal or even unnoticeable. The key is to sync data carefully and switch DNS only after the new site is ready.
What should I check if the domain points to the new server but the site still looks old?
Check browser cache, CDN cache, reverse proxy cache, and application cache. Also confirm that the new server is serving the correct document root and that no old static assets are being loaded from the previous host.
Should I keep the old hosting account after migration?
Yes, at least for a short period. Keeping the old hosting active helps absorb late DNS traffic and gives you a fallback if you need to compare files, logs, or settings during the transition.
Conclusion
A migrated website is not always live everywhere at the same moment. The switch depends on DNS propagation, cache expiration, and how the migration was prepared. For most websites on European hosting platforms, users begin reaching the new site within minutes to hours, while full global consistency often takes up to 24 hours and sometimes longer.
If you want the fastest and safest result, lower TTL before the move, keep the old environment online briefly, verify both A and AAAA records, clear caches, and test the site across multiple networks. That approach gives you a smooth DNS switch and a more reliable live cutover with fewer surprises.