The principle

Do not start by rewriting. Do not start by shipping a feature. Start by answering three questions in writing:

1. What exists (code, data, accounts, integrations, docs)?
2. Who can break what (admins, deploy keys, DNS, billing)?
3. How do we change something safely (staging, backups, rollback)?

Until those answers are good enough, every "quick fix" is a bet against production. The same ownership mindset as a 30-minute account audit applies here, but scoped to the whole product, not only logins.

Handover quality varies. Sometimes you get a clean repository and a paid knowledge transfer. Sometimes you get a zip file and silence. The phases below still work. They compress when the previous developer cooperates, and they expand when they do not.

Phase 1: Inventory without touching production

Build a living inventory before you change behaviour. Capture at least:

• Code: repositories, branches that actually deploy, build commands, lockfiles, private packages.
• Runtime: hosts, containers, serverless functions, cron jobs, queues, workers.
• Data: databases, object storage, backups, retention, who pays for the volume.
• Identity: domains, DNS, TLS certificates, email sending domains, SSO, API keys.
• Integrations: payment, CRM, email, analytics, AI providers, webhooks in both directions.
• People access: who is admin where, personal vs organisation accounts, shared passwords.
• Docs and tickets: READMEs, runbooks, architecture notes, open bugs, known landmines.

Mark each item owned / shared / unknown. Unknown is not shameful. Leaving it unmarked is. If documentation at delivery was thin, rebuild what you can from configs and history using the lens of the documentation you should demand at delivery. You are writing it for the next person, who might be you in six months.

Phase 2: Stabilize access and backups

Before refactors, make sure you can survive a bad week.

• Get admin where it matters. Org owner on Git, hosting, DNS, cloud, app store, payment, email. Personal accounts under the previous developer are temporary bridges, not a plan.
• Prove restore. A backup you never restored is a story. Restore a recent copy to a throwaway environment and time how long it takes.
• Freeze risky changes. Agree a short freeze on DNS, billing contacts, and production schema while inventory finishes, unless something is already on fire.
• Secure secrets. Move credentials into a vault you control. Rotate anything that lived in chat, a spreadsheet, or a laptop you no longer trust.
• Protect customer data in tests. Do not clone production into a shared staging box. Follow GDPR and test environments from day one of the takeover.

If the previous person is leaving the organisation, run access removal as a parallel track with the offboarding checklist. Taking over the project without removing their lingering admin is half a job.

Phase 3: Make the system understandable

You need a mental model good enough to change one thing without breaking three others.

• Map the happy path. One user journey from entry to money or outcome, with the services it touches.
• Map deploy. Commit to production: CI, secrets, migrations, feature flags, who presses the button.
• List cron and webhooks. Silent jobs and inbound callbacks are where "we did not touch anything" outages live.
• Note debt that is load-bearing. Ugly code that holds revenue is not the same as ugly code you can delete.
• Reproduce locally or in staging. If you cannot run it, you cannot safely change it. Fix that before big features.

Write a short architecture note (even two pages). Link real paths and commands. Prefer facts over opinions about the previous stack.

Phase 4: Regain the ability to change safely

Ownership without a safe change path is theatre. Build the minimum runway:

• Staging that mirrors production closely enough for the risky parts
• A documented deploy and rollback
• Monitoring or at least error alerts on the critical path
• A place for tickets and decisions you own (not only their private chat)

If DNS or mail will move as part of reclaiming accounts, treat that as its own project. See migrating DNS without breaking your email. If you inherit SaaS tools you plan to leave later, keep export rights and a sync plan in mind: gradual replacement usually needs both a clean exit path (leaving a SaaS without losing your data) and careful dual-running (syncing two systems: the five ways it breaks).

Phase 5: Improve under control

Only now schedule product work with clear risk levels.

• Keep the lights on: security patches, certificate renewals, dependency alerts, unpaid invoices on critical vendors.
• Small wins: observability, missing docs, flaky deploys, one painful manual step automated.
• Strategic changes: module rewrites, host moves, SaaS exits, data model changes. One major risk at a time.

Publish a simple roadmap to the client-side owner: what is stable, what is fragile, what you will not touch yet. Takeovers fail socially when stakeholders expect feature velocity on day three while you are still finding which account owns the TLS cert.

Rewrite or keep

A full rewrite is seductive after a messy handover. It is also how many companies lose a year and rebuild the same bugs with nicer folders.

Keep and harden when the product makes money, users know the quirks, and the main pain is ownership, deploys, or missing docs. Most takeovers land here.

Rewrite in slices when a boundary is clear (billing, admin, one mobile screen) and you can dual-run or feature-flag. Prefer strangler patterns over a big-bang cutover.

Rewrite wholesale only when several of these are true: stack cannot be hired for, security or compliance is untenable, vendor is shutting down, or the cost of change in the old system exceeds rebuild for the scope you actually need. Even then, migrate data with a plan, not hope.

Decide with evidence from phases 1 to 4, not with disgust at the first file you open.

Working with the previous developer

Cooperation is an asset. Hostility is a risk to schedule around, not a personality project.

• Paid knowledge transfer. Book fixed sessions with an agenda: deploy, secrets, landmines, unpaid invoices, "what would you fix first". Record them if allowed.
• Written answers beat oral lore. Ask for a document. Follow up in email so facts leave their head.
• Access before opinions. Get admin on critical systems while they still answer. Arguments about code style can wait.
• Assume goodwill until proven otherwise. Many "bad" codebases are the result of changing briefs and unpaid discovery, not malice.
• If they vanish. Do not wait forever. Proceed with inventory, registrar and host support, and legal counsel if accounts or IP are blocked. Parallel: stop new dependency on anything only they can unlock.

Contract considerations

The commercial frame decides whether you inherit rights or only a running demo. Align the takeover with contract clauses to demand from any tech provider.

• IP and source. Confirm assignment or licence that lets a new developer continue without the previous one's permission.
• Access and non-withholding. Credentials, repos, and admin must transfer on exit. Silence in the old contract is a negotiation problem now.
• Warranty window. Clarify what the previous party still fixes, until when, and how bugs are reported.
• Your new engagement. Scope the takeover as its own phase: inventory, stabilize, document, then build. Mixing "take over and ship feature X by Friday" hides the real work.
• Liability for past debt. Say explicitly what you accept responsibility for after which date, especially security incidents and unpaid vendor bills discovered mid-takeover.

Common mistakes

• Rewriting in week one because the code "looks bad".
• Changing DNS early to "clean ownership" and breaking mail or SSL.
• Leaving personal accounts in place "for a bit" until they become the only way to deploy.
• Shipping features with no staging because "it always worked for them".
• Copying production data into a shared test box to go faster.
• Skipping offboarding of the previous developer while celebrating the new hire.
• Promising dates before inventory is honest.
• Trusting chat history as the system of record for secrets and decisions.

Checklist

Access and ownership

• Inventory of accounts, repos, hosts, DNS, billing contacts
• Organisation admin on every critical system (or a dated plan to get it)
• Secrets in your vault, rotated where exposure is likely
• Previous developer access reduced or removed per offboarding plan

Safety net

• Backup restore tested to a non-production target
• Staging (or equivalent) usable for risky changes
• Deploy and rollback documented and tried once
• Alerts on the critical path, or a temporary manual watch agreed

Knowledge

• Architecture note with real paths and commands
• List of cron, webhooks, and third-party dependencies
• Known landmines and open incidents written down
• Rewrite vs keep decision recorded with reasons

Commercial

• IP and source rights confirmed for continued development
• Takeover phase scoped separately from feature delivery
• Warranty or support boundary with the previous party clear
• Client-side owner named for decisions during the takeover

Le principe

Ne commencez pas par réécrire. Ne commencez pas par livrer une fonctionnalité. Commencez par répondre par écrit à trois questions:

1. Qu'est-ce qui existe (code, données, comptes, intégrations, docs) ?
2. Qui peut casser quoi (admins, clés de déploiement, DNS, facturation) ?
3. Comment changer quelque chose en sécurité (staging, sauvegardes, rollback) ?

Tant que ces réponses ne sont pas assez bonnes, chaque « correctif rapide » est un pari contre la production. Le même réflexe de propriété qu'un audit de comptes en 30 minutes s'applique ici, mais sur tout le produit, pas seulement les logins.

La qualité de passation varie. Parfois vous avez un dépôt propre et un transfert de connaissances payé. Parfois une archive zip et le silence. Les phases ci-dessous tiennent quand même. Elles se compriment si le développeur précédent coopère, et s'étendent s'il ne coopère pas.

Phase 1: Inventaire sans toucher la production

Construisez un inventaire vivant avant de changer le comportement. Capturez au minimum:

• Code: dépôts, branches qui déploient vraiment, commandes de build, lockfiles, packages privés.
• Runtime: hôtes, conteneurs, fonctions serverless, crons, files, workers.
• Données: bases, stockage objet, sauvegardes, rétention, qui paie le volume.
• Identité: domaines, DNS, certificats TLS, domaines d'envoi email, SSO, clés API.
• Intégrations: paiement, CRM, email, analytics, fournisseurs d'IA, webhooks dans les deux sens.
• Accès humains: qui est admin où, comptes perso vs organisation, mots de passe partagés.
• Docs et tickets: README, runbooks, notes d'architecture, bugs ouverts, mines connues.

Marquez chaque élément possédé / partagé / inconnu. Inconnu n'est pas une honte. Le laisser sans marque, oui. Si la documentation à la livraison était maigre, reconstruisez ce que vous pouvez depuis configs et historique avec le regard de la documentation à exiger à la livraison. Vous l'écrivez pour la personne suivante, qui peut être vous dans six mois.

Phase 2: Stabiliser accès et sauvegardes

Avant les refactors, assurez-vous de survivre à une mauvaise semaine.

• Obtenir l'admin là où ça compte. Propriétaire d'org sur Git, hébergement, DNS, cloud, store, paiement, email. Les comptes perso du développeur précédent sont des ponts temporaires, pas un plan.
• Prouver la restauration. Une sauvegarde jamais restaurée est une histoire. Restaurez une copie récente vers un environnement jetable et chronométrez.
• Geler les changements risqués. Convenez d'un court gel sur DNS, contacts de facturation et schéma de production pendant que l'inventaire finit, sauf incendie déjà en cours.
• Sécuriser les secrets. Déplacez les identifiants dans un coffre que vous contrôlez. Faites tourner tout ce qui a vécu dans un chat, un tableur ou un portable dont vous ne vous fiez plus.
• Protéger les données clients en test. Ne clonez pas la production dans une staging partagée. Suivez RGPD et environnements de test dès le premier jour de la reprise.

Si la personne précédente quitte l'organisation, menez le retrait d'accès en parallèle avec la checklist d'offboarding. Reprendre le projet sans retirer ses admins restants, c'est un demi-travail.

Phase 3: Rendre le système compréhensible

Il vous faut un modèle mental assez bon pour changer une chose sans en casser trois autres.

• Cartographier le parcours nominal. Un trajet utilisateur de l'entrée jusqu'à l'argent ou au résultat, avec les services touchés.
• Cartographier le déploiement. Du commit à la production: CI, secrets, migrations, feature flags, qui appuie sur le bouton.
• Lister crons et webhooks. Les jobs silencieux et les callbacks entrants sont là où vivent les pannes « on n'a rien touché ».
• Noter la dette porteuse. Du code moche qui tient le chiffre d'affaires n'est pas la même chose qu'un code moche qu'on peut supprimer.
• Reproduire en local ou en staging. Si vous ne pouvez pas le faire tourner, vous ne pouvez pas le changer en sécurité. Corrigez ça avant les grosses fonctionnalités.

Écrivez une courte note d'architecture (même deux pages). Liez des chemins et des commandes réels. Préférez les faits aux opinions sur la stack précédente.

Phase 4: Retrouver la capacité de changer en sécurité

La propriété sans chemin de changement sûr est du théâtre. Construisez la piste minimale:

• Un staging assez proche de la production sur les parties risquées
• Un déploiement et un rollback documentés
• Du monitoring ou au moins des alertes d'erreur sur le chemin critique
• Un endroit pour tickets et décisions que vous possédez (pas seulement leur chat privé)

Si le DNS ou le mail doit bouger pour reprendre les comptes, traitez cela comme un projet à part. Voir migrer le DNS sans casser l'email. Si vous héritez d'outils SaaS que vous quitterez plus tard, gardez les droits d'export et un plan de sync: le remplacement progressif demande souvent une sortie propre (sortir d'un SaaS sans perdre ses données) et un double fonctionnement prudent (synchroniser deux systèmes: les cinq façons de casser).

Phase 5: Améliorer sous contrôle

Seulement maintenant planifiez le travail produit avec des niveaux de risque clairs.

• Garder les lumières allumées: correctifs de sécurité, renouvellements de certificats, alertes de dépendances, factures impayées chez des fournisseurs critiques.
• Petites victoires: observabilité, docs manquantes, déploiements fragiles, une étape manuelle douloureuse automatisée.
• Changements stratégiques: réécriture d'un module, déménagement d'hôte, sorties SaaS, changements de modèle de données. Un risque majeur à la fois.

Publiez une feuille de route simple pour le propriétaire côté client: ce qui est stable, ce qui est fragile, ce que vous ne toucherez pas encore. Les reprises échouent socialement quand on attend de la vélocité produit au jour trois alors que vous cherchez encore quel compte possède le certificat TLS.

Réécrire ou garder

Une réécriture complète séduit après une passation salissante. C'est aussi ainsi que beaucoup d'entreprises perdent un an et reconstruisent les mêmes bugs avec de plus jolis dossiers.

Garder et durcir quand le produit fait de l'argent, que les utilisateurs connaissent les bizarreries, et que la douleur principale est la propriété, les déploiements ou les docs manquantes. La plupart des reprises atterrissent ici.

Réécrire par tranches quand une frontière est claire (facturation, admin, un écran mobile) et que vous pouvez faire tourner en parallèle ou avec feature flags. Préférez le pattern strangler à une bascule big-bang.

Réécrire en entier seulement si plusieurs de ces points sont vrais: stack impossible à recruter, sécurité ou conformité intenables, éditeur qui ferme, ou coût du changement dans l'ancien système supérieur à une reconstruction pour le périmètre réellement nécessaire. Même alors, migrez les données avec un plan, pas avec de l'espoir.

Décidez avec les preuves des phases 1 à 4, pas avec le dégoût du premier fichier ouvert.

Travailler avec le développeur précédent

La coopération est un actif. L'hostilité est un risque à caler dans le planning, pas un projet de personnalité.

• Transfert de connaissances payé. Réservez des sessions à agenda fixe: déploiement, secrets, mines, factures impayées, « que corrigiez-vous en premier ». Enregistrez si c'est autorisé.
• Les réponses écrites battent le lore oral. Demandez un document. Relancez par email pour que les faits quittent leur tête.
• Accès avant opinions. Obtenez l'admin sur les systèmes critiques pendant qu'ils répondent encore. Les débats de style de code peuvent attendre.
• Supposez la bonne foi jusqu'à preuve du contraire. Beaucoup de « mauvaises » bases sont le résultat de briefs changeants et de découverte non payée, pas de malice.
• S'ils disparaissent. N'attendez pas éternellement. Poursuivez inventaire, support registrar et hébergeur, et conseil juridique si comptes ou PI sont bloqués. En parallèle: arrêtez toute nouvelle dépendance à ce que seuls eux peuvent déverrouiller.

Points de contrat

Le cadre commercial décide si vous héritez de droits ou seulement d'une démo qui tourne. Alignez la reprise avec les clauses de contrat à exiger de tout prestataire tech.

• PI et sources. Confirmez une cession ou une licence qui permet à un nouveau développeur de continuer sans la permission du précédent.
• Accès et non-rétention. Identifiants, dépôts et admin doivent être transférés à la sortie. Le silence dans l'ancien contrat est un problème de négociation maintenant.
• Fenêtre de garantie. Clarifiez ce que la partie précédente corrige encore, jusqu'à quand, et comment les bugs sont signalés.
• Votre nouvel engagement. Cadrez la reprise comme une phase à part: inventaire, stabiliser, documenter, puis construire. Mélanger « reprendre et livrer la feature X pour vendredi » cache le vrai travail.
• Responsabilité sur la dette passée. Dites explicitement ce que vous assumez après quelle date, surtout incidents de sécurité et factures fournisseurs découvertes en pleine reprise.

Erreurs fréquentes

• Réécrire en semaine une parce que le code « a l'air mauvais ».
• Changer le DNS trop tôt pour « nettoyer la propriété » et casser le mail ou le SSL.
• Laisser les comptes perso en place « un moment » jusqu'à ce qu'ils deviennent le seul moyen de déployer.
• Livrer des features sans staging parce que « chez eux ça marchait toujours ».
• Copier les données de production dans une boîte de test partagée pour aller plus vite.
• Sauter l'offboarding du développeur précédent en célébrant la nouvelle embauche.
• Promettre des dates avant que l'inventaire soit honnête.
• Faire confiance à l'historique de chat comme système de référence pour secrets et décisions.

Checklist

Accès et propriété

• Inventaire des comptes, dépôts, hôtes, DNS, contacts de facturation
• Admin d'organisation sur chaque système critique (ou plan daté pour l'obtenir)
• Secrets dans votre coffre, rotés là où l'exposition est probable
• Accès du développeur précédent réduits ou retirés selon le plan d'offboarding

Filet de sécurité

• Restauration de sauvegarde testée vers une cible hors production
• Staging (ou équivalent) utilisable pour les changements risqués
• Déploiement et rollback documentés et essayés une fois
• Alertes sur le chemin critique, ou veille manuelle temporaire convenue

Connaissance

• Note d'architecture avec chemins et commandes réels
• Liste des crons, webhooks et dépendances tierces
• Mines connues et incidents ouverts écrits
• Décision réécrire vs garder enregistrée avec motifs

Commercial

• Droits PI et sources confirmés pour poursuivre le développement
• Phase de reprise cadrée séparément de la livraison de features
• Frontière de garantie ou support avec la partie précédente claire
• Propriétaire côté client nommé pour les décisions pendant la reprise