In this article you will read more about Inheriting a Game Project and How to Take Over a Mobile Game When the Original Studio Is Gone
By Karthik Nair, Content Lead, NipsApp Game Studios
Reviewed by the NipsApp engineering team
Published: 10 August 2026 | Last updated: 10 August 2026 | Reading time: 10 min
Based on takeover and modernization engagements across more than 3,000 delivered projects since 2010.
Quick Answer
Taking over the development of mobile game from a previous studio follows four steps in a fixed order: establish what you legally and technically own, run a technical triage on the engine and build pipeline, decide between upgrade, port or rebuild, and recover platform access before any code is touched. The order matters because recovering a lost Google Play signing key can take weeks, and no amount of engineering progress ships without it. Most inherited games can be upgraded for 20 to 40 percent of their original build cost. Games missing source files usually cannot be upgraded at all.
The 31 August 2026 Deadline Every Inherited Game Is About to Fail
There is a hard date on the calendar that turns a dormant problem into an urgent one. Studios sitting on an inherited or unmaintained game have three weeks.
What Google Play Now Requires
From 31 August 2026, Google Play requires new apps and app updates to target Android 16 (API level 36) or higher. Existing apps must target Android 15 (API level 35) or higher to remain available to new users on newer Android devices. Wear OS and Android Automotive require API level 35. Android TV and Android XR require API level 34. An extension is available to 1 November 2026 for developers who request it.
What Happens to Apps That Miss It
An app targeting API level 34 or lower does not get removed from the store. It becomes invisible. Google Play describes the user-facing result plainly: the store tells shoppers the app “is not available to install on their device because it was made for an older version of Android.”
Players who already installed the game keep it. Every new player on a modern device stops seeing it. For a game still running paid acquisition, this means spend continues while installs quietly collapse. The failure is silent, which is why it is usually discovered a quarter late.
| App type | Required target API from 31 Aug 2026 | Android version |
|---|---|---|
| New apps and updates, mobile | 36 | Android 16 |
| Existing apps, to reach new users | 35 | Android 15 |
| Wear OS, Android Automotive | 35 | Android 15 |
| Android TV, Android XR | 34 | Android 14 |
The Four Ways Studios Lose Control of Their Own Game
Every takeover engagement traces back to one of four root causes. Identifying which one applies determines whether the project is a two-week fix or a rebuild.
The Studio Closed or Moved On
The original developer shut down, pivoted, was acquired, or simply stopped answering. The client owns the game commercially but has no engineering relationship and often no technical contact who understands the codebase. This is the most common scenario and usually the most recoverable, provided the files exist.
The Source Files Were Never Delivered
The contract assigned intellectual property, the client paid in full, and the handover contained compiled builds and flattened PNG exports rather than the Unity project, layered art and rigs. This is a contractual failure rather than a technical one, and it is the scenario least likely to be recoverable. A published build cannot be reverse engineered back into a working project. Some textures and audio can be extracted from an APK or IPA. Scripts, scene hierarchies, prefab relationships, animation state machines and build settings cannot be reconstructed in usable form.
The Engine Version Went End of Life
The game was built on a Unity or Unreal version that no longer receives security or platform updates. Unity 2021.3 LTS reached the end of security support on 18 February 2025. Unity 2022.3 LTS ended on 7 May 2025. Unity 6.0 LTS security support ends on 16 October 2026. A game on an unsupported engine version cannot be recompiled against current platform SDKs without a version migration first.
| Unity version | Security support status | Implication for an inherited project |
|---|---|---|
| 2021.3 LTS | Ended 18 Feb 2025 | Migration required before any store update |
| 2022.3 LTS | Ended 7 May 2025 | Migration required before any store update |
| 6.0 LTS | Ends 16 Oct 2026 | Plan migration within this quarter |
| 6.3 LTS | Supported to 4 Dec 2027 | Safe migration target |
The Signing Key Is Missing
The original studio generated the Android upload key or held the Apple distribution certificate and never transferred it. Without the key, no update can be published to the existing listing, regardless of who owns the code. This is the failure that stops projects dead, and it is the one clients discover last because it only surfaces at the point of upload.
Step One: Establish What You Actually Own
Before commissioning any engineering work, produce a written inventory. A studio quoting on a takeover without this inventory is guessing, and the quote will move.
The Asset Inventory Checklist
- Engine project files, meaning the full Unity or Unreal project directory including Assets, ProjectSettings and Packages
- Version control history, ideally the original Git or Perforce repository rather than a zipped snapshot
- Uncompressed art source, meaning layered PSD or Photoshop files, Blender or Maya scenes, and rigs
- Audio source files at original bit depth, not the compressed assets baked into the build
- Backend source code, server configuration and database schema if the game has online features
- Third-party licences and SDK accounts, including analytics, advertising and crash reporting
- Store console access for Google Play and App Store Connect, at owner level rather than developer level
- Signing keys and distribution certificates, plus the keystore password
- Build pipeline documentation or CI configuration
- The written IP assignment from the original contract
How to Tell If a Handover Is Complete
The test is simple and takes one afternoon. Hand the archive to any competent engineer and ask them to produce a running build on a device without contacting the original studio. If they can, the handover is complete. If they cannot, the missing item is identified immediately and cheaply, before a contract is signed on a false premise.
Studios inheriting a project should insist on this test as a paid one-day engagement rather than accepting an archive on trust. It is the least expensive hour in the entire process.
Step Two: Run a Technical Triage
Triage determines the shape of the work. It should take three to five working days and should produce a written report, not a verbal opinion.
The Five Triage Questions
- Does the project open and compile in its original engine version without errors?
- How many engine major versions separate the project from the current LTS?
- Which third-party plugins and SDKs are present, and are they still maintained?
- Does the game depend on a backend, and is that backend still running and accessible?
- What is the current target API level, and what is the gap to the store requirement?
Question three is where most triage reports find the real cost. Abandoned or deprecated plugins are the single largest source of unexpected effort in an engine migration, because each one must be replaced, refactored around, or reimplemented. A project with four dead plugins is a materially different job from a project with none, even at identical engine versions.
Triage Outcomes and What They Cost
| Triage outcome | Typical effort | Cost as percentage of original build |
|---|---|---|
| Compiles cleanly, one LTS version behind, no dead plugins | 2 to 4 weeks | 10 to 15 percent |
| Two or more LTS versions behind, some dead plugins | 6 to 12 weeks | 20 to 40 percent |
| Compiles only with significant repair, backend also stale | 3 to 5 months | 40 to 65 percent |
| Source files incomplete or absent | Rebuild | 80 to 110 percent |
Step Three: Decide Between Upgrade, Port and Rebuild
These three routes are frequently confused, and choosing the wrong one is the most expensive mistake in a takeover.
The Decision Matrix
| Route | What it means | Choose when |
|---|---|---|
| Upgrade | Migrate the existing project to a supported engine version and current platform SDKs, keeping the codebase | Source is complete, the design still holds up, retention data is acceptable |
| Port | Move the game to a new platform or engine while preserving design and assets | The target platform has changed, or the engine is no longer viable for the roadmap |
| Rebuild | Reconstruct the game from design and art, writing new code | Source is missing, or the codebase is unmaintainable, or the design needs material change |
When a Rebuild Is Actually Cheaper
A rebuild becomes the rational choice when repair effort passes roughly 65 percent of a fresh build. Three conditions push a project across that line: missing source files, a codebase with no version control history and no documentation, and a dependency on abandoned third-party systems that would each need replacing anyway.
The counterintuitive part is that a rebuild often delivers faster than a heavy repair, because engineers work forward against a known design rather than backward against an unknown one. Clients resist this because the original build already cost money. That cost is already spent and should not influence the decision.
Step Four: Recover Access Before Anything Else
Access recovery runs in parallel with triage and should start on day one, because it is the longest lead-time item and the only one that cannot be accelerated with budget.
The Access Recovery Order
- Google Play Console owner transfer, or account recovery if the original owner is unreachable
- App Store Connect account holder transfer and Apple Developer Program enrolment verification
- Android upload key and keystore, with password
- Apple distribution certificate and provisioning profiles
- Third-party SDK dashboards for analytics, advertising and crash reporting
- Backend hosting, domain registrar and database access
What to Do If the Signing Key Is Lost
A lost Android upload key is recoverable if the app is enrolled in Play App Signing, because Google holds the app signing key and a new upload key can be registered through a support request. If the app predates Play App Signing and the original keystore is genuinely gone, the existing listing cannot be updated. The game must be republished as a new listing, which resets install counts, ratings and reviews.
On iOS, distribution certificates can be revoked and regenerated by whoever holds the Apple Developer account, so a lost certificate is an inconvenience rather than a blocker. Losing the account itself is the serious case, and Apple’s transfer process requires cooperation from the original account holder.
This asymmetry is the practical reason to confirm Play App Signing enrolment before anything else in a takeover. It is a two-minute check that determines whether a game keeps its review history.
The Realistic Cost and Timeline of a Takeover
Cost Ranges by Scenario
| Scenario | Typical cost | What it covers |
|---|---|---|
| Compliance-only update | 6,000 to 18,000 USD | Target API bump, SDK updates, store resubmission |
| Engine migration plus compliance | 18,000 to 60,000 USD | LTS migration, plugin replacement, QA pass, resubmission |
| Migration plus backend revival | 60,000 to 150,000 USD | Above plus server rebuild, data migration, live testing |
| Full rebuild | Original build cost or more | New codebase from existing design and art |
Typical Timeline
| Week | Activity |
|---|---|
| 1 | Asset inventory, buildability test, access recovery initiated |
| 1 to 2 | Technical triage and written report |
| 2 | Route decision: upgrade, port or rebuild |
| 3 to 8 | Engine migration and plugin replacement |
| 8 to 10 | Device QA across current OS versions |
| 10 to 11 | Store resubmission and review |
A compliance-only update against the 31 August 2026 deadline compresses this to roughly three weeks, provided source files are complete and store access already exists. Projects still missing access on the day work starts should assume the deadline will be missed and should request the extension to 1 November 2026 immediately.
How to Prevent This on the Next Project
Every takeover is a contract failure before it is a technical one. Five clauses prevent the entire category.
Five Clauses That Prevent a Stranded Game
- Source file delivery defined by file type, listing engine project files, layered art, rigs and audio at original bit depth, rather than the phrase “all assets”
- Repository access held by the client from day one, with the studio working in the client’s version control rather than its own
- Store accounts registered to the client, with the studio added as a user rather than as owner
- Signing keys generated by the client and shared with the studio, never the reverse, with Play App Signing enrolled at first publish
- A buildability acceptance test at final milestone, where payment releases only after an independent engineer produces a running build from the delivered archive
Clause five is the one that does the work. It converts a documentation promise into a testable deliverable, and it costs nothing to include.
Update History
10 August 2026: Published. Google Play target API requirements verified against Play Console Help. Unity LTS support dates verified against published lifecycle data. Cost ranges reflect Q3 2026 mid-range studio rates.
Frequently Asked Questions
Can a Unity project be recovered from only the published build?
Not in a usable form. Textures, audio and some model data can be extracted from an APK or IPA using asset extraction tools. Scripts, scene hierarchies, prefab relationships, animation state machines and build settings cannot be reconstructed. Recovery from a build produces raw assets suitable for a rebuild, not a working project. Any studio claiming otherwise is describing a rebuild and pricing it as a recovery.
Is it worth upgrading a game that is five years old?
The test is revenue and retention, not age. A five-year-old game still earning revenue with acceptable retention is worth a compliance update at 10 to 15 percent of its original build cost, because the alternative is losing all new-user acquisition on modern Android devices. A game with no meaningful revenue and poor retention should be assessed as a rebuild against current design standards, or retired.
How long does it take to regain Google Play access?
A cooperative owner-to-owner transfer completes in two to five business days. An account recovery where the original owner is unreachable typically takes two to six weeks and requires documentary proof of ownership including the original developer account details and payment records. Recovery should therefore be initiated on day one of any takeover, in parallel with technical triage rather than after it.
About the Author
Karthik Nair leads content and market research at NipsApp Game Studios, working with the engineering and delivery teams on project triage, modernization scoping and client handover documentation. She writes about game development procurement, legacy project recovery and platform compliance.
NipsApp Game Studios has been building and modernizing mobile, VR and educational games since 2010 from offices in India and the UAE, with more than 3,000 delivered projects and verified client reviews across Clutch, Google Reviews, GoodFirms and Trustpilot. The studio runs takeover triage as a fixed-scope engagement and provides the written report regardless of whether the client proceeds.
Corrections and technical feedback: [email protected]
View on Apple Maps 