Phased Migration: How to Launch a Redesign Without Losing Traffic
This article is part of the Flatstudio × Stavka.tv case study. Written for product teams and developers who need to do more than just ship a new design — they need to move a live audience onto it without losing traffic or search rankings. Main article in the series — here.
--------
Three years of work. One domain. The forecast: a 25–50% traffic drop and roughly a month to recover. That's what a major migration usually looks like — first a fall, then a slow climb back. We prepared for the worst and got something completely different.
Why Major Redesigns Drop at Launch
There's a mistake almost every team makes during a big redesign: they evaluate whether the design is ready, but not whether the transition is. They think about how good the new site looks — not about how to move a million people onto it without Google deciding the site has disappeared.
With Stavka.tv, we understood the risks early. The platform runs on organic traffic — SEO isn't a channel for them, it's oxygen. Over 3 million visits a month by the time version 2.1 was ready to launch. If Google "lost" the site for even a week during reindexing, that would be a real hit to both users and ad revenue.
So we didn't just launch. We migrated.
[→ screenshot: traffic graph August–November 2022 with transition date marked]
Three Waves Instead of One Day
We broke the launch into three phases.
First wave (September 8, 2022). New.stavka.tv — a separate domain with noindex. Access was given only to "Pros" and "Experts" — the most active and loyal users, roughly 2% of the audience. These people understood the product better than anyone: they noticed small things, gave specific feedback, and didn't leave after the first confusing change. Perfect testers — not because we labeled them that way, but because they'd made themselves that over years of using the platform.
New.stavka.tv stayed invisible to Google. The old version on the main domain kept getting indexed and collecting traffic as usual.
Second wave. Opening the new version to all registered tipsters — 100% of active users. At this stage we also deployed popups and an onboarding flow for the new interface: people could see the changes but weren't left to figure everything out alone.
Third wave (October 19, 2022). The switch. The new version becomes the main stavka.tv domain with indexing enabled. The old site moves to old.stavka.tv and stays there for a few more weeks — in case something went wrong and a rollback was needed.
[→ diagram: three circles labeled "2% pros → noindex", "100% registered users", "main domain → old.stavka.tv archived"]
Why We Moved Faster
The third wave was originally planned for later. But in October 2022, we realized: exactly one month remained before the FIFA World Cup in Qatar.
Stavka.tv lives on football. The World Cup is the biggest event of the year. Launching a new site in the middle of the tournament — or right after — means burning your most valuable traffic window on users getting used to a new interface. Better to ship everything early, give it a week or two to stabilize, and enter the tournament already running on the new version.
October 19 — decision made, transition done.
What the Numbers Showed
Two weeks after the transition, Viktor Titov posted a summary in the team chat.
"We predicted that our traffic would drop 25–50% after the migration and take about a month to recover. But we managed to smooth out almost all the disruption — we barely dipped even in the short term, and within a week we were back to baseline numbers."
More specifically, here's what changed:
On top of that, October 2022 turned out to be a record month: 3 million visits and 900,000 unique users — the best numbers in the platform's history at that point.
These metrics didn't "recover after a drop." There was almost no drop. They improved immediately after the transition and stayed at the new level.
[→ 🎆 table or infographic: four metrics before/after]
The Number That Surprised Us Most
Bounce rate and time on site are expected metrics to track. But +100% profile page visits is a different conversation.
In version 2.1, we substantially rebuilt the profile system: rankings, prediction statistics, divisions. People started visiting each other's profiles — not because we pushed them there, but because the system became interesting enough to do it voluntarily. Doubling profile visits in the first month meant the social mechanic had worked the way we'd intended back at the concept stage.
If traffic is quantity, then time on site and pages per visit are quality. Profile visits are a signal about whether users experience the platform as a community — or just as a collection of pages.
What We Did Right (and What We'd Do Differently)
Three things that worked:
Noindex on the test domain. While the new version lived on new.stavka.tv, Google didn't see it. Zero risk of duplicate indexing, traffic cannibalization, or confused ranking signals.
The old site stayed live. old.stavka.tv kept accepting traffic for several weeks after the switch. If something had gone wrong, we could have flipped back. That parachute was never used — but knowing it existed gave us the confidence to act decisively.
Documentation of temporary decisions. Every project has places where a developer did something "for now, we'll fix it later." Without documentation, those places live forever. We agreed: every temporary decision in the code gets written down separately, with an explanation of why and what's planned instead. This kept technical debt from accumulating as unknowns.
What we'd do differently: the first wave was planned for September 1st and actually happened on the 8th. A week's delay — because of last-minute fixes that always surface at the end. Next time, we'd build that buffer in officially rather than treating it as "just a few more days."
The Migration Is a Product Too
The most important lesson from this launch: the go-live strategy needs to be designed with the same care as the product itself.
Designers often think their responsibility ends where development begins. Or that a release is the PM's and DevOps's problem. But if the migration fails, the design fails with it. Users don't distinguish between "a poorly designed site" and "a poorly executed launch."
We thought about the risks before writing the first frame in Figma. So on October 19, 2022, when the new version became the main domain, it wasn't a jump into the water — it was a planned crossing over a bridge we'd been building with the client for months.
--------
If your product has reached the stage of a major redesign and you're thinking about how not to break what's already working — that's exactly the moment to talk about Post-MVP Evolution. Not after launch. Before it.
← Back to the main article in the series: "Sports Predictions Platform: An 8-Year Case Study with 3M Monthly Visits"
Other articles in the series:
→ Rebranding a Sports Platform: How We Built a Brand System Across 10+ Touchpoints
→ From 2.0 to 2.1: How We Rewrote Two Years of Work Without Losing the Client
→ Promo for Bookmakers: Why Headers Convert at Zero and Popups Actually Work
→ Design Systems for Complex Products: Why It's an Investment, Not an Expense
Frequently Asked Questions
Who are these solutions best suited for?
We design around complex, high-stakes products rather than simple marketing sites. Our solutions are best suited for B2B and B2C SaaS, fintech, sports tech and iGaming teams dealing with high-load dashboards, internal tools, betting platforms or multi-platform ecosystems. Most of our clients are startups and scale-ups that need a consistent design and engineering partner instead of a one-off creative studio.
What's the difference between a fixed‑price sprint and a long‑term retainer?
Fixed‑price sprints (like Fundraising Concept or Product Audit & Discovery) have a clearly defined scope, timeline and deliverables — for example, a 4‑week concept sprint or a 2–3 week audit. They are ideal when you need a sharp, focused outcome. Long‑term retainers (like Post‑MVP Evolution or Dedicated Product Units) are built for continuous evolution: we join your roadmap, work in sprints, and adjust priorities as your product and metrics change. You get a predictable monthly budget and an embedded team instead of re‑negotiating every feature.
How do I choose between Pitch Deck & Product Concept, Post‑MVP Evolution, Product Audit & Discovery, and Product Rebuild & Redesign?
Pitch Deck & Product Concept is for 0→1 founders who need to raise capital before writing production code – we turn your vision into an investable narrative and clickable concept. Post‑MVP Evolution is for Seed / Series A teams with a live product that needs faster iteration, stronger UX and a real design system. Product Audit & Discovery is for products facing churn, stagnation or negative feedback – we diagnose UX and tech friction and give you a prioritised roadmap. Product Rebuild & Redesign is for mature or legacy platforms that have hit a growth ceiling – we modernise brand, UX and code without breaking the business logic that already works. If you’re unsure, we start with a short discovery call and map your current stage to the right model.
How is "Engineering Design" different from a regular creative agency?
Regular agencies optimise for “wow” moments and campaigns. We optimise for systems and product performance. We treat design like code: modular, scalable and logic‑driven. Instead of drawing standalone screens, we build design systems, patterns and documentation that your developers can implement without guessing. That’s why our solutions always combine product & interface design, brand identity, web app engineering and marketing assets into one coherent system.
Do you work with startups or only established companies?
Both. Our clients range from early-stage founders raising their first round to enterprise teams scaling complex platforms with millions of users.
What do clients value most about working with Flatstudio?
Clients consistently highlight three things: deep industry knowledge, logical and scalable design systems, and honest communication. We challenge weak decisions early rather than executing them blindly.
.png){kind=small}
