A website migration, especially a move to a new domain, sounds like a DNS change. Technically it nearly is: redirecting one domain to another takes a single rule and happens in the blink of an eye. The impact is another matter. Move a live product to a new domain and you are touching revenue, SEO rankings built up over years, analytics history, email deliverability and customer trust, all at once, with the site staying up the whole time. Now multiply that by three. This is a case study of moving a UK telecom brand’s three products, each with its own blog, customer support and live chat, from .uk domains to a .com in four weekly phases, with zero downtime and no data lost.
The migration at a glance
| Company | A UK telecom brand selling across the UK, Europe and the United States |
| Scope | Three products (a mobile service, a calling app with its backend APIs, and calling cards), each with its own site, blog, customer support and live chat |
| Move | .uk domains to a single .com |
| Size | Thousands of product and blog URLs, around 50,000 visitors |
| Approach | Four phases, one a week, each monitored before the next |
| Teams | Frontend and backend engineering, DevOps, marketing, customer support |
| My role | Product manager: owned the sequencing, the risk, the rollback plan and the communication |
| Result | Zero downtime, no data lost, more traffic after the move, and a .com that opened the way to multilingual, multi-country sites |
Why move from .uk to .com
The .uk domains had worked well enough for years. But the brand was selling across Europe and the United States, and a .uk address tells every customer and every search engine that the business is British. For a customer in Germany or New York, that is a weak signal. A .com gave the brand a neutral global home, and with it the option to run language and country versions of each site under one domain.
What was at stake
Each of the three products had its own address, and the calling app also had backend APIs that its mobile apps depended on. Each product also had its own blog, its own customer support and its own live chat. That is at least a dozen customer-facing properties, plus the APIs behind the apps, all moving to a new domain, and every one of them carried its own risk.
Downtime on a product site meant lost revenue in real time. A mishandled redirect on any of the blogs meant years of accumulated SEO equity disappearing. An app calling an API on the old domain meant customers unable to use the product at all. A support article or chat widget still pointing at the old domain meant a customer with a problem hitting a dead end at exactly the wrong moment. Broken analytics meant flying blind during the window when visibility mattered most. And any disruption to email meant customers losing trust in a brand that had just changed its address.
None of these risks were independent. A DNS mistake could cascade across every product at once. And going by the teams’ own history, nobody expected this to be smooth. That is what made it a product problem rather than a pure infrastructure task: someone needed to own the sequencing and bring everyone along, not just run the technical steps.
The product manager’s job in a migration
As product manager on this migration, my job was not to run DNS changes or write redirect rules. It was to make sure the transition met five conditions at once, for every product:
- Zero downtime across every site, app, blog, help centre and chat
- Preserved SEO rankings, analytics continuity and email reliability
- Customer confidence maintained throughout
- Every team onboarded early and aligned on the same sequence and the same rollback plan
- A working rollback path at every stage, not just a plan on paper
That last point matters more than it looks. A rollback plan that has not been tested is a false sense of security. Every phase of this migration was built so that if something went wrong, the team could revert without customers noticing.
How the migration was sequenced: one phase a week
The single decision that made the biggest difference was refusing to move everything at once. The redirect itself takes seconds, but its effects do not. DNS changes can take 24 to 48 hours to reach everyone. Search engines and AI crawlers can take about a week to notice the move and crawl the new pages, and nobody can say exactly how long they will take to drop the old domain and index the new one. So we planned one migration a week, giving each phase time to settle and be monitored before starting the next:
- Week 1: the mobile service and the calling app: their websites, the apps and the backend APIs the apps call.
- Week 2: both products’ blogs.
- Week 3: the knowledge base and customer support.
- Week 4: the calling cards product, repeating the same cycle: site, blog, then support.
With each move, the new sitemaps were submitted so search engines could find the new URLs instead of waiting to stumble on them.
Four weeks sounds slower than a single cutover. It is not, once you account for the cost of diagnosing a failure across a dozen or more interdependent properties at the same time. Moving in phases meant that if something broke, the team knew exactly where to look, and the blast radius stayed inside one phase instead of spreading across the whole product family.
The one thing that nearly went wrong
Week 3 was the knowledge base, which ran on a third-party platform. After the move it stopped working, and the natural assumption was that the provider was having an outage. It was not. That integration needed its SSL certificate regenerated for the new domain, a step none of the other properties had needed. Once the certificate was reissued, it came straight back.
Two things kept this from becoming a crisis. It happened in its own phase, so it was clear which piece had broken. And the week-long gap meant there was time to find the real cause instead of rushing on to the next move with a problem still open.
Staging, QA and cross-functional alignment
Before any phase went live, staging and QA environments were set up to test routing, redirects, cookies, authentication and caching under conditions that matched production as closely as possible. This is the unglamorous work that decides whether a migration is boring or a crisis, and it happened before execution, not during it.
The migration also depended on clear ownership across teams, brought in early rather than told on the day:
- Frontend and backend engineering handled URL structures, application routing and the APIs behind the apps
- DevOps managed DNS and SSL cutover
- Marketing validated SEO signals and the redirect maps for each blog
- Customer support prepared responses ahead of each change, so customer questions had answers on day one instead of being improvised
Underneath all of it, email redirection and analytics continuity were maintained throughout, with real-time monitoring so the team could catch a problem in minutes rather than discover it days later in a traffic report.
The result
All three products moved with zero downtime and no data lost, across thousands of URLs and around 50,000 visitors. Traffic grew after the move rather than dipping. The bigger win came afterwards: on a .com, the brand could finally go multilingual and run country versions of its sites, so customers in Europe and the United States saw a native brand rather than a British one.
Just as important, the teams stayed aligned and confident rather than reactive. Given their history, they had expected a rough transition. What made the difference was not heroics but planning, early onboarding of every stakeholder, and clear communication at each step.
A website migration checklist from this project
This is what the plan came down to. It applies to most domain moves and replatforming projects, and especially to anything with more than one product or subdomain.
- List every property before you plan. Here each product had a site, a blog, a support centre and live chat, and the app had backend APIs. Each of those breaks in its own way.
- Split the move into phases, and leave time between them. One phase a week gave DNS time to settle and the team time to watch the impact before moving on.
- Write a rollback path for each phase, not just one for the whole project, and test it.
- Map every old URL to its new one before anything moves, and have marketing check each redirect map against the pages that carry your rankings.
- Submit the new sitemaps as each phase goes live, so search engines find the new URLs quickly.
- Test in staging under production-like conditions: routing, redirects, cookies, authentication and caching.
- Check SSL on every third-party integration, not just your own servers. Hosted help centres and similar tools may need their certificates reissued for the new domain.
- Give each risk a named owner, and bring every team in early: engineering for URLs, routing and APIs, DevOps for DNS and SSL, marketing for SEO signals, support for customer questions.
- Move support and live chat deliberately. Help-centre links and chat widgets tied to the old domain are easy to miss, and they are where customers notice first. Prepare support answers before launch day, not during it.
- Keep analytics and email running across the switch, and monitor in real time after each phase, so a problem shows up in minutes, not in next week’s traffic report.
What this means if you are planning a migration
Big transitions rarely fail because people did not work hard enough. They fail because clarity and sequencing were missing before anyone started moving fast. Breaking the work into phases, giving each one time to settle and bringing stakeholders in early reduces risk far more reliably than trying to finish quickly.
If a domain migration, replatforming effort or any other high-stakes technical transition is on your roadmap, the questions worth asking upfront are the same ones this migration answered before execution. What is the rollback plan for each phase, not just the whole project? Who owns which risk, and have they actually tested their part in staging? Which of your properties depend on a third party you do not control? And is the plan sequenced so that a failure in one phase stays contained, instead of taking the rest of the system down with it?
If you want someone to own that plan for your team, this is the kind of work I do as a technical product manager.
For more on how sequencing and stakeholder alignment show up in product decisions beyond migrations, see The Prism of Priorities: Seeing Beyond Stakeholder Noise. And for a look at the kind of technical risk that shows up the moment a site is live and public, see Your Website Is Being Scanned Right Now.
Tahir Shahzad
Tahir Shahzad is a Product Manager, Product Owner, and technology consultant with over a decade of experience helping startups and organizations build products people actually use. If you are working on a product problem worth solving, reach him at tahirshahzad.com/contact/
