Changing providers, taking over software after the departure of a key developer, or recovering an acquired application is not just about transferring a Git repository. A production application depends on a much broader set: cloud accounts, certificates, scheduled tasks, backups, third-party services, operating procedures, business knowledge, and historical decisions.
The first few weeks determine the quality of the future relationship. A team that immediately starts developing new features without securing this environment risks discovering dependencies at the least favorable moment: during an incident or a production deployment.
The 90-day method aims to regain control without unnecessarily immobilizing the product. It combines securing, understanding, stabilizing, and building a roadmap.
Before the transfer: define what actually needs to be handed over
Reversibility must be prepared before the switch date. The first list concerns assets: source code, history, tickets, documentation, diagrams, design files, tests, deployment scripts, container images, and licenses.
The second concerns access: hosting, DNS, certificates, database, storage, transactional email, monitoring tools, CDN, package registries, mobile accounts, app stores, payment services, analytics platforms, and backups. For each access, it is necessary to know the legal owner, the administrators, the recovery method, and the rotation process.
The third concerns business operations. Which processes cannot be interrupted? Which operations require manual handling? What exchanges are expected by partners? Which incidents are recurring? What commitments have been made to users?
An incomplete inventory does not always prevent resumption. However, it turns the missing areas into explicit risks and priority tasks.
Phase 1 — Day 0 to Day 15: secure and make observable
The first step is not to 'clean the code.' It consists of making sure that the application can be observed, backed up, and recovered.
The team confirms access, removes obsolete accounts, enables enhanced authentication whenever possible, and organizes the rotation of secrets. It checks backups, their retention, and especially the possibility of restoration. It inventories certificates and subscriptions that could silently expire.
At the same time, it reconstructs the production deployment path: building, configuration, database migrations, deployment, cache clearing, worker restart, and rollback. A first execution must be carried out in a non-production environment. If this path is not reproducible, any change is temporarily classified as risky.
Monitoring must cover the essential signals: availability, error rate, response time, saturation, disk space, queues, scheduled task failures, and backup health. The goal is not to immediately install a complex platform, but to prevent an incident from being discovered by the end client.
Phase deliverables: access inventory, list of immediate risks, contact procedure, backup proof, simplified operating map, and first dashboard.
Phase 2 — Day 15 to Day 45: understand and document
Once the minimum continuity is ensured, the team rebuilds the architecture and the main business rules. They set up the project on a clean environment, run the tests, observe the logs, and follow some real requests from end to end.
The interviews are short and focused. The job describes the critical operations and exceptions. The former provider, when available, explains the sensitive areas, undocumented procedures, and choices that seem strange without their context. The operations describe recurring incidents and manual handling.
The code is analyzed according to the nine dimensions of a technical audit: architecture, maintainability, dependencies, security, data, performance, testing, operations, and transferability. The goal is not yet to fix every flaw, but to know where a modification is safe and where it requires additional safeguards.
The documentation produced must be immediately useful: local startup, architecture, external flows, deployment procedures, restoration, scheduled tasks, environment matrix, and business glossary. Exhaustive documentation that is never reviewed is less useful than a short guide checked by a new person.
Phase deliverables: mapping, user guide, dependency register, initial audit, and list of remaining unknowns.
Phase 3 — Day 45 to Day 90: stabilize and restore the capacity for progress
The third phase addresses the risks that prevent normal work. Priority fixes generally concern backups, permissions, vulnerable dependencies, silent errors, unstable tasks, and deployment procedures.
The most sensitive career paths are protected by characterization tests. These tests describe the current behavior, even when the code is not yet ideal. They then allow gradual modification without reinventing the rules.
The team is also building an upgrade strategy. Dependencies are categorized into simple updates, migrations to prepare, and components to replace. Performance improvements are based on measurements. Pending functional requests are re-evaluated in light of the new technical constraints.
Finally, the stakeholders validate a roadmap across three horizons: securing, modernization, and product evolution. Each project specifies its benefit, its risk, its dependencies, and its scale.
Phase deliverables: stabilized version, prioritized test coverage, reliable delivery pipeline, ranked backlog, and negotiable roadmap.
After 90 days: switch to controlled maintenance
Routine maintenance is based on a visible framework. Requests are qualified, incidents have a procedure, changes are traceable, and versions are subject to a policy. The indicators focus on service quality, not just the number of tickets closed.
A healthy operation particularly follows: availability of critical paths, detection time, recovery time, deployment failure rate, age of dependencies, coverage of risky paths, and volume of unplanned work.
Knowledge must remain distributed. Journals, reports, tested procedures, and on-call rotations prevent recreating a dependency on a single person with the new provider.
The timeline begins before the transfer with the inventory of assets, access, and business rules. From Day 0 to Day 15, the priority is to secure access, backups, deployments, and monitoring. From Day 15 to Day 45, the team reconstructs the architecture, documents operations, and identifies unknowns. From Day 45 to Day 90, it stabilizes the priority risks, protects sensitive processes through testing, and builds the roadmap. The current regime then maintains service quality and shared knowledge.
Difficult scenarios and the appropriate response
The former provider is not cooperating
Start by securing what belongs to the client: domains, contractual accounts, data, repositories, and backups. Document each missing item and its impact. Avoid unverified technical accusations; focus discussions on assets and reversibility obligations.
The recovery team will have to rebuild part of the knowledge from the code, configurations, logs, and users. This work must be planned as such, not silently absorbed into maintenance.
The code contains no test
It would be unwise to immediately launch a general refactoring. Identify the high-impact flows, capture their current behavior, and add tests around stable interfaces. Logs, anonymized data copies, and end-to-end tests can provide initial protection before a more detailed coverage.
The hosting is not documented
Establish a map from the outside in: DNS, CDN, firewalls, load balancers, servers, containers, databases, storage, tasks, and external services. Check invoices and consoles to spot resources invisible in the code. Do not delete anything without an observation period and proof of uselessness.
The application is already experiencing incidents
Separate the 'restore service' flow from the 'understand and modernize' flow. Set up an incident unit, temporary priorities, and a freeze on non-essential changes. Each incident should enrich the mapping and protections rather than trigger a succession of isolated fixes.
What the customer must keep at the end of the take-back
A successful takeover is not measured solely by the fact that the new provider knows how to intervene. The client must regain control of their assets and decisions. They must have an inventory of accounts, minimally verified documentation, visibility on risks, an exit procedure, and an understandable budget.
Environments must be reproducible, backups restorable, productions traceable, and accesses nominative. The backlog must distinguish corrective maintenance, technical debt, security, evolutions, and business requests.
The value of a gradual recovery
The temptation is strong to take advantage of the team change to rewrite everything. Yet, the first 90 days often reveal that some building blocks are reliable, that business rules are more complex than announced, and that the urgencies are not where one thought.
A structured takeover preserves what works, first reduces risks, and creates the conditions for rational modernization. Partitech knows how to take over the maintenance of projects developed by third parties and support their evolution over time, from auditing to hosting and IT management.
To frame the transition, start with a complete technical audit of the application, then discover how to prepare for reversibility and the change of provider. The offer Maintenance, updates, and hosting and our reference of financial business platform supported over time complete this approach.
Official references
References checked on August 17, 2026: