T-minus 48 hours: final preparations
Before you even think about putting up a maintenance page, there are a few things to lock down.Reduce your DNS TTL (if applicable)
If you’re not using a CDN (or switching CDN backends), you’ll need to change DNS records. That means dealing with cache. Here’s the move: Lucas on DNS preparation:“If you need to change DNS, lower your TTL in advance. We usually suggest dropping it to 30 seconds. That way, when you make the switch, you’re not waiting hours for the cache to expire. Most of your traffic will flip over quickly.”Do this 48-72 hours before migration, not the day of. DNS changes take time for caches to expire, including the TTL value itself.
Communicate with your users
This might sound obvious, but it’s worth emphasizing: tell people the site will be down. Lucas on user communication:“If you can, put a banner on the site in advance: ‘Between X time and Y time, the site will be unavailable.’ And here’s the key: always overpromise on downtime. Say you’ll be down for an hour when you’re planning for 30 minutes. If you finish early, users are pleasantly surprised. If you say 30 minutes and take an hour and three minutes, they’re disappointed.”Under-promise, over-deliver. It works in migrations too.
Pre-generate TLS certificates (CDN users)
If you’re using Fastly or another CDN with Upsun, you can pre-generate TLS certificates using DNS validation. This means no waiting for certificate generation during your cutover window. Lucas explains the approach:“For clients using our CDN, we provide a CNAME for verification, and we pre-generate the TLS certificates. Then there’s no delay when you switch over. You can even test with a subdomain first, like prod.yourdomain.com pointing to the new infrastructure while www.yourdomain.com still points to the old one.”This isn’t always possible (Upsun Cloud doesn’t support DNS validation for certificates yet), but where it is, use it.
Run one final sync
If you’ve set up database replication or have done a practice run of file copying, do one last sync of your data 24-48 hours before migration. This gives you:- Confidence that the process works
- A baseline for how long the final sync will take
- A chance to catch any issues before you’re under time pressure
The maintenance window
Alright. It’s time. You’ve told your users, you’ve prepared your team, and you’re about to put the site into maintenance mode.Where to put the maintenance page
You have options here:- CDN level: If you’re using Fastly or another CDN, set the maintenance page there. This is ideal because it doesn’t hit your origin at all.
- Application level: Many CMS platforms and applications support a maintenance mode flag (often just a database flag or a file in the filesystem).
“I recommend putting maintenance mode on both sides. Why? Because the maintenance flag in your application (a database flag or file) will get copied during the migration. So when you bring the new system online, it’s already in maintenance mode. Then you can verify everything works before you lift the flag.”This prevents the scenario where you flip DNS, users hit the new site, and it’s live before you’ve verified it works.
Wait for workers to drain
If you use background workers (RabbitMQ, queues, etc.), don’t jump straight to copying data. Wait for the queues to empty. Lucas on worker queues:“RabbitMQ is nice because it’s easy to see when queues are empty. Put the site in maintenance, then let workers finish consuming whatever’s in the queues. Once they’re empty, then you proceed with the migration. Otherwise you might lose jobs that were in flight.”For search services like Elasticsearch or Solr, you’ll typically need to reindex on the new platform. If you’ve been using database replication, your data should be current, so reindexing can be fast (or even partial/incremental).
The cutover sequence
Here’s the order of operations. These can often run in parallel (if network isn’t your bottleneck), but this is the logical sequence:1. Final file sync with rsync
You’ve been using rsync for practice runs. Now you do it for real. Because rsync does differential copying, and because you’ve (hopefully) organized your files into a reasonable directory structure, this should be quick. Lucas on rsync timing:“The differential copy with rsync is great. It only copies what’s changed. But if you have 15,000 files in one folder, even counting them all takes time. That’s why file organization matters.”
2. Database cutover
If you’re using replication: Promote the replica to primary. This is nearly instantaneous. If you’re using a dump: You’re importing the database, and this is your longest step. The good news is you’ve timed this during your practice runs, so you know how long it takes. The bad news is it’s mostly incompressible time. Lucas on database imports:“If you’re using a dump, this is the long part. The dump itself is small (it doesn’t include index structures), but rebuilding indexes on the other side takes time. You can’t do much to speed it up beyond giving the database service more resources temporarily.”(Learn more about why database dump sizes differ from actual database size) Pro tip: If metrics show a bottleneck during your practice import, you can temporarily upsize the database service just for the import, then size it back down. The cost is minimal (you’re only upsized for an hour at most), and it can save meaningful time.
3. Service migrations (Redis, search, etc.)
Some services you can’t easily migrate:- Redis: No dump import support in Upsun (requires RDB or AOF files). For cache uses, you can just start fresh. For persistent data, you’ll need a different strategy.
- Elasticsearch/Solr: Reindex from your database (which should be current if you used replication).
4. DNS switch (or CDN origin switch)
Once data is in place: If you’re using a CDN: Just change the origin backend. This is instant and doesn’t involve DNS cache. If you’re not: Change your DNS records to point to Upsun. Even with a 30-second TTL, give it a few minutes for most traffic to flip over.Verification before going live
Here’s the clever bit: you’re going to verify everything works before you lift the maintenance page.The IP whitelist trick
Most CDNs and many applications let you exclude certain IPs from the maintenance page. Lucas on IP whitelisting:“With Magento, for example, you can say ‘everyone sees the maintenance page except these three IPs.’ Those three IPs are your team. So you can browse the site, make a test purchase, edit content, whatever you need to verify, all while the rest of the world sees the maintenance page.”This is your safety net. If something’s broken, users never see it.
What to verify
Your verification depends on your application, but generally you’ll want to confirm:- Homepage loads correctly
- Login works (test with a real account)
- Key workflows function (checkout, form submission, content editing, etc.)
- HTTP headers confirm requests are hitting Upsun (not the old platform)
- Static assets load (images, CSS, JS)
- Critical integrations work (payment processing, email, etc.)
The /etc/hosts trap
Here’s a gotcha that’s caught more than one team: Lucas shares a cautionary tale:“We had a client testing during maintenance. They said ‘looks good, but something’s weird.’ Turned out they’d been testing with a manual entry in their /etc/hosts file for weeks, and they forgot about it. So their browser was hitting the old platform while they were checking the database via SSH on the new platform. They couldn’t figure out why test purchases didn’t show up in the database.”The lesson: Check your headers. Make sure the response headers show you’re hitting Upsun, not your old host. If you’ve been using /etc/hosts for testing, remove those entries before final verification.
Post-migration: the first 24 hours
You’ve verified everything. You’ve lifted the maintenance page. Users are back on the site. You’re not done.Monitoring: What to watch
Lucas on post-migration vigilance:“After the migration, I tend to be a bit obsessive for the first half hour or hour. I’m watching metrics, trying to do a purchase, editing an article, checking if everything still works. Once I’m confident everything’s good, then I can relax.”What to monitor:
- Upsun metrics dashboard: Watch container resource usage, response times, error rates
- Blackfire: Keep an eye on performance profiles
- Your own monitoring: If you have external monitoring (uptime checks, etc.), make sure those are green
- Error logs: SSH into your environment and tail logs to catch any issues immediately
- Fix forward (if it’s a configuration issue you can address quickly)
- Roll back (if it’s catastrophic, though this is rare if you’ve tested properly)
Enable uptime SLA monitoring
Once you’re confident the site is stable, this is a good time to enable Upsun’s Uptime SLA monitoring if you haven’t already. Lucas on support handoff:“We recommend asking support to enable Uptime SLA monitoring. That way, if something goes wrong after hours, Upsun’s support team gets notified and can react. It’s the handoff from migration specialist to ongoing support.”
Resist the urge to deploy changes immediately
You’ve just migrated. The site is working. Resist the temptation to start deploying new features or making changes in the first day or two. Let it stabilize. Make sure normal traffic patterns look healthy before you introduce new variables.The two-week follow-up period
The migration isn’t over when the site is live. There’s a follow-up period where you’re settling into the platform, and where Upsun’s onboarding team is still watching. Lucas on the follow-up:“We follow clients for 7 to 14 days after migration. We keep an eye on the site, and at the end, we do what’s called a post-go-live call. We review what went well, gather feedback, and for larger clients, we introduce key members of the support team.”(Note: This follow-up support is part of Upsun’s Onboarding & Migration Services. Many clients work with the OMS team for additional coordination and support throughout the migration process.)
The support handoff
One thing Lucas mentioned that caught my attention: many clients are nervous about moving from their dedicated onboarding specialist to general support. Lucas on putting a face to support:“We found that clients were often afraid of support—afraid they’d get a chatbot, afraid they’d get someone who doesn’t know what they’re doing. So we started bringing a support manager and a senior support engineer to the post-go-live call. Just putting a face to support, showing them ‘this is a real person, they know what they’re doing,’ that alone reassures people tremendously.”It’s a small thing, but it matters. You’re not getting shuffled off to some faceless ticket system. You’re meeting the people who’ll help you going forward.
Settling into platform workflows
During this two-week period, you’ll continue using the Upsun workflows you practiced during Phase 3 testing, now applying them to your live production environment:- Creating development environments for new features
- Running deployments through Git
- Using the CLI for debugging and management
- Following the platform’s patterns and best practices
Rollback: the reality
Let’s talk about something uncomfortable: what if you need to roll back? Lucas on rollback planning:“We don’t really encourage setting up bidirectional replication so you can roll back easily. Most of our clients are coming from hosting that’s ending or nearly ending. They’re in a time crunch. Rolling back isn’t high on their priority list.”That said, if something goes catastrophically wrong and you need to roll back:
- Your old platform probably still exists (at least for a few days)
- You can export data from Upsun if needed (no vendor lock-in)
- Any transactions that happened on the new platform during the brief live period can typically be exported and handled manually
“If it’s broken enough that you need to rollback, users usually aren’t successfully completing transactions anyway. If the whole site is broken, there aren’t purchases to worry about. And if you catch issues during the verification phase (before lifting maintenance), you never went live at all.”This is why testing and verification matter. You want to find showstopper issues while you’re still behind the maintenance page.
Making migration day boring
If you’ve done everything right, here’s what your migration day looks like:- Put up maintenance page
- Wait for workers to drain
- Run rsync for files (fast, because it’s differential)
- Promote database replica (instant) or import dump (timed, but expected)
- Reindex search if needed
- Switch DNS or CDN backend
- Verify everything while still in maintenance
- Lift maintenance page
- Monitor for the first hour
- Go home
Read Part 1: Planning Your Upsun Migration for the complete planning roadmap that leads up to migration day.