Hand Over a Live Game to a LiveOps Partner
We took the questions studios ask most often when they hand over a live game, turned them into the fears behind them, and asked Varun Menon, Senior Game Producer on our mobile game LiveOps services team, to answer.
You are thinking about handing over your live mobile game to an external LiveOps partner.
Your head is full of questions you may not want to say out loud.
The fears we hear most
This game is years of our work. How do we find a team that understands it and takes it over smoothly?
What if they break the part that makes money?
How would I even know what they are doing?
How do you hand over a live mobile game?
Plan a phased transition with overlap between the 2 teams, share dashboards and goals from day 1, and agree rollback steps before anything breaks. For the first 30 days, change nothing big: shadow the old team, fix small bugs, and write down the why behind every process.
Varun Menon
Senior Game Producer, Devoted Studios
13+ years in games and live operations, with Ubisoft, EA and NetEase in the background. At Ubisoft Pune, Varun owned the live product lifecycle for Trials Frontier and Just Dance Now and held P&L responsibility. Varun also led the transfer of live products from lead studios to Pune, establishing new teams, workflows and operational cadence. Has worked with teams across Toronto, Pune, Finland and Hangzhou. PMP and PSM-1 certified.
What a LiveOps producer actually signs up for
“A LiveOps producer keeps a live game healthy and growing. On the development side, it means making sure the team always knows what’s shipping next, with clear goals and deliverables.”
Varun Menon, on the job of a LiveOps producerTrust
“This game is years of our work. How do we find a team that understands it and takes it over smoothly?”
You preserve control over your project.
That hesitation is completely valid. A studio that developed a title from scratch hasn’t merely created code or design. It survived every development challenge, successfully cultivated a passionate player base, and established a dependable revenue engine. Entrusting that product to an external group is a massive leap of faith.
Transitioning, however, doesn’t need to feel like jumping off a cliff. Look for:
- 1A phased transition period.Ensure adequate overlap and active participation alongside your core team.
- 2Unified metrics and reporting.Establish shared operational dashboards and objectives right away.
- 3Failsafes and safety nets.Set up concrete rollback procedures should complications arise.
- 4Total operational visibility.Maintain joint syncs where everyone tracks identical performance metrics.
Executed correctly, you preserve control over your project while freeing your internal talent to focus on future initiatives.
At Devoted, you choose the level you plug us in at, and you keep control either way.
Three ways to plug us in
Our ramp is weeks, with a ramp plan from day one.
The first month
“They’ll walk in, ‘fix’ everything in week 1, and break the part that makes money.”
Varun was asked what the first 30 days of a takeover should look like. His answer is the opposite of that fear.
Listen, learn, and change nothing.
Listen, learn, and change nothing. The team that’s been running the game has built a huge amount of knowledge, culture and process around it, and you need to understand all three before you touch anything. So for the first month, you shadow their processes and ask “why does this work this way?” a lot.
You shouldn’t just watch, though. Work alongside the previous team: fix bugs, contribute small pieces of content, and build real hands-on experience running the game. A new team usually arrives with plenty of ideas for improving things, and that’s great, but I’d hold off. What looks broken in week 1 often makes sense by week 4, and priorities shift as you learn.
The first 30 days, as Varun describes them
Knowledge
“A lot of what makes this game work lives in a few people’s heads. Will it survive the handover?”
This is a common problem: a lot of knowledge lives in a few people’s heads. So how do you make sure nothing is lost in a handover? Here is what Varun recommends, starting with the “why.”
Documentation tells you what a team does, but almost never why.
The “why.” Why the economy is tuned the way it is. Why an event always launches on a specific day. Which config flag you must never touch. Which tool only works with a workaround. Documentation tells you what a team does, but almost never why. 3 things help:
- 01The new team writes the runbooks while doing the work. If the outgoing team writes them, you won’t find the gaps until something breaks.
- 02Record walkthroughs of every critical process. Seeing someone do it beats reading about it.
- 03Check your “bus factor.” Every critical task should have at least 2 people who’ve actually done it, not just read about it.
Firefighting
“How do I know if my own team is stuck in firefighting mode?”
The sprint plan you agreed on Monday is already irrelevant by Wednesday.
You can usually spot it within a week of joining. The sprint plan you agreed on Monday is already irrelevant by Wednesday, and the team ships more hotfixes than planned releases. Events get thrown together the week before they go live instead of being built calmly over a month. It’s always the same handful of people staying late to keep things running, and if you ask anyone what’s shipping 6 weeks from now, you get a shrug. The last sign is often the most telling: postmortems either don’t happen at all, or they happen and the action items quietly never get closed, so the same fires keep coming back.
Revenue
“How do I know the numbers my partner shows me are real wins?”
Varun was asked 2 things: how thinking about revenue changes the way he plans events and updates, and which metric he watches most closely and which one can be misleading.
It looks fantastic on the day, but often it just pulls spending forward.
Viewing events through a revenue lens shifts them from simple content drops to testable hypotheses. Every release starts with a clear objective, such as driving retention or boosting payer conversion, followed by a transparent evaluation of the results. Event scheduling must align with real-world player rhythms, including holidays, school schedules, and paydays, while pacing offers carefully to avoid exhausting core spenders. Crucially, monetization shouldn’t drive every initiative; purely player-centric events build long-term goodwill that yields returns down the line. Ultimately, managing a P&L teaches you to plan in seasons rather than single events, as current actions establish the foundation for future engagement.
The metric I watch most closely is retention, especially among engaged players and payers, because if those people start drifting away, nothing else on the dashboard really matters. The one I’m most careful with is a big revenue spike from a single offer or event. It looks fantastic on the day, but often it just pulls spending forward, and you quietly pay for it with a dip 2 weeks later. Averages like ARPPU can be just as misleading, since a small group of high spenders can easily mask what’s happening to the rest of your players.
Visibility
“A team in another time zone. How would I know what they’re doing?”
Transparency really comes down to never making the client wonder what’s going on.
Transparency really comes down to never making the client wonder what’s going on. That means working in the same tools, so the client sees the same tracker and dashboards we do. It means a predictable rhythm of updates they can count on, and sharing bad news early rather than hoping it goes away. A written log of decisions also helps, so nobody has to rely on memory to recall who agreed to what.
I’ve worked across Toronto, Pune, Finland and Hangzhou over the years, and the biggest lesson has always been the handoff. A clear end-of-day note means the team in the other time zone starts its morning already knowing exactly what happened, instead of losing half a day catching up.
And the team itself. Our team in Canada brings together Engineering, Design, Art & QA, and many of us have spent years at studios like Ubisoft, EA, Certain Affinity, NetEase, and others, so the team is senior by default. These are people who have shipped AAA and live titles before and know what good looks like without needing hand-holding. Being based in North America also means our clients get real-time collaboration during their working day, rather than waiting overnight for answers.
Choosing
“Everyone says they’re experienced. What do I actually ask?”
Ask these 3 questions.
Any good partner should have a real story and real numbers ready.
- Q1“Can you show me a game you took over mid-flight, what did your first 90 days look like, and what happened to the KPIs?”Any good partner should have a real story and real numbers ready.
- Q2“What will I see, and how often?”That covers dashboard access, reporting cadence, and most importantly, how bad news gets escalated to you.
- Q3“Who exactly will be on my team, and how long have they been with you?”When it comes to running a live game, seniority and low turnover matter far more than headcount.
From our side
Directors behind our work
Six directors with decades of combined industry experience stand behind our LiveOps work: production, engineering, creative direction, art and technical art. Meet the whole team
Mobile games our team has worked on
Forza Customs
Olympic Jam
Angry Birds
Pudgy Party
NASCAR Manager
TMNT: Splintered Fate
Treasure Party: Puzzle Fun!
Rainbow RumbleThe LiveOps Partner Checklist
Everything Varun covered, boiled down to 23 checks in 5 groups: before the handover, the first 30 days, what you should see, what to ask the partner, and a check on your own team. Take it to your next partner call and tick each one off before you sign.
1. Before the handover
2. The first 30 days
3. What you should see
4. Ask the partner
5. Is your own team in firefighting mode?
We hope this article was useful. And if you want a hand with your own game, our professional LiveOps team can step in and help.
