Powstania Warszawskiego 15
31-539 Kraków
Changing development teams on an app that already has users is an ownership problem before it is a code problem. This is what has to be in your hands before a new team can ship anything, the order the transition should run in, and how to tell whether your app should be taken over or rebuilt.
Moving a live mobile app to a new development team is an ownership transfer before it is a technical one. Five things decide whether it works: developer accounts held by your own company, the repository with its history and the commit that produced the live version, the release credentials, owner level access to the backend and every third party service, and an honest account of what is unreleased. Run the audit while the previous team is still reachable, move access before work, and make the first release change almost nothing.
Rarely the code. What stops a new team is access: developer accounts registered in someone else's name, credentials held by one person who has moved on, services billed to a card the client cannot see. Every week spent chasing that is a week with no releases.
In our own projects, the most common client side delay has one cause: access to third party services and store accounts arriving late. On a new build that shows up around the time the first release is due. On a takeover it shows up on day one.
That is because everything already exists: a live app, paying users, and a published version that somebody has to be able to replace. The clock starts before the new team has written anything.
The second pattern is quieter. Companies come to us after a project elsewhere went wrong, and the cause is almost never that the previous team could not write software. It is that the software answered the wrong question, because the supplier understood the framework and not the operation.
That matters during a transition, because it changes what you are buying. If the app is technically sound and simply built against a misunderstanding of your business, a rewrite is the expensive answer to a scoping problem. If the app is built correctly against the right problem and just has no one maintaining it, what you need is app maintenance, not a new project.
Five things. Until all five are yours, a new team can read your app but cannot ship it, and any date it gives you is conditional on somebody else answering an email.
The store listing, its history, its ratings and its subscribers are tied to the account that publishes the app, not to the people who wrote it. If that account belongs to your previous supplier, your users belong to your previous supplier too.
Owner level rights on both accounts, held by your legal entity, with the outgoing team moved to a role you are able to revoke.
History is how a new team answers the questions that decide the estimate: when this stopped working, what was tried before, which parts are still moving. An archive of files with no history hides all of it.
Access to the repository itself, plus the exact commit or tag that produced the version currently installed on your users' phones.
Signing material is the one asset in a handover that is genuinely hard to replace. It is also the one most often held informally, on the laptop of whoever set the project up years ago.
The signing configuration and a written statement of where the keys live, who holds them today, and what happens if they are lost.
Most apps quietly depend on six to ten external services: hosting, database, authentication, push, analytics, error reporting, payments, maps. Each one has an owner and a payer, and they are not always the same company.
An owner level account on each service and a list of which card is being charged for what, so nothing expires mid transition.
Every live app has work in flight: a branch that was almost finished, a feature behind a flag, a fix that shipped to one platform and not the other. This is the part that never makes it into a formal document.
The open branches, the last three releases and what each one changed, and a straight answer on what is unreleased today.
None of this requires the outgoing team to be cooperative, but it is significantly cheaper when they are. Collect it while the relationship still works, not after you have told them you are leaving.
A handover is finished when the new team can publish a release on its own, not when the code lands in your repository.
Audit first, while the old team is still reachable. Move access second. Ship a deliberately boring release third. Only then start the work that made you change teams in the first place.
The boring release is the step most often skipped, and it is the one worth defending. A codebase that compiles on a developer machine is not the same thing as a release path that works, and the difference only becomes visible in the real environment.
We have learned that repeatedly on our own builds. On TimeFix, a field service app, the requirement that the work timer must keep counting while a technician locks the screen or takes a call from inside the app never came from a specification. It came from technicians using it on real jobs. Environments produce facts that documents do not.
Whether the app can be built and released from a clean machine, what it actually does versus what it is documented to do, and which parts of it are yours rather than a template. Without those three, an estimate is a guess with a decimal point.
Once those are answered, work on an inherited codebase can be quoted the same way as new work. That is how we run it: an audit, then a written scope, then a fixed price for the first phase. If you want the commercial models side by side first, they sit on our pricing page and in our breakdown of mobile app development cost.
One finding changes the audit more than any other: whether the app is used in an office or in the field. Apps that run in basements, vans and plant rooms carry assumptions about connectivity and data that are invisible until someone reads the sync code, which is why we treat them separately in field service app development, custom HVAC software development and offline first app development.
When the account ownership cannot be recovered, when the product was generated rather than written, when the platform version gap is wider than a rebuild, or when the business question changed so much that the existing app answers something you no longer ask.
The no code case is the most common one we see. A product built in a visual builder and then exported behaves like a draft of an app rather than an app, and continuing on the export is often slower than moving deliberately. We wrote up how that transition works in practice in our guide to FlutterFlow to Flutter migration.
The second case is scope drift. If the operation the app was built for has changed shape, keeping the old structure means paying twice: once to understand it, once to bend it. In that situation the honest recommendation is to treat the existing app as research and scope a first version properly, the way we do for startup MVPs.
The reverse is worth saying too. Plenty of apps we are asked to rebuild do not need rebuilding. They need someone answering for them every week, which is a much smaller commitment than a new project and is priced accordingly in our guide to app maintenance cost.
Five questions separate a team that has done this before from one that will learn on your app. All five can be asked on a first call, and the answers tend to be revealing.
There is one warning sign worth watching for on that first call, and it comes from the projects we inherit. A supplier that asks about your technology before it asks about your operation is telling you which of the two it intends to optimise.
The questions we think belong on a first call are collected in our guide to briefing an app development company, and the stage by stage view is in working with an app development agency.
Teams working from Poland on a nearshore model take over apps for clients across Europe and for companies in New York, which in practice means the transition calls sit in your morning or your afternoon rather than at midnight.
Not if the app stays in the same store listing, which is the normal case when you own the developer accounts. Users keep the app, their data and their settings, and see only an ordinary update. This is precisely why account ownership is worth settling first.
They belong to the listing rather than to the code, so keeping the listing keeps them. Moving an app between developer accounts is possible, but it is a formal process with conditions attached, and it should be planned deliberately rather than discovered halfway through a transition.
Usually yes, and it is slower. The audit then works from whatever access exists plus what is observable in the published app, and recovery routes exist for accounts registered to your own company. The cost of a silent predecessor is measured in weeks, not in whether it can be done.
Yes, after an audit. We scope the first phase from what the audit found and quote it as a fixed price, so the unknowns are priced once rather than billed monthly. Anything the audit could not see stays outside that scope and is named explicitly.
Both. Flutter is the larger part of our portfolio, and React Native work runs through the same process, described on our page for the React Native team. The framework changes the audit findings, not the order of the transition.
Yes. Some transitions are not a replacement at all but extra capacity on an app your own people maintain, which we run as a developer joining an existing team. The access questions in this article still apply, just with fewer of them outstanding.
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Send us what you have and we will tell you what a takeover would involve, what the first release should be, and what it would cost as a fixed price.
30 minutes, no preparation needed.