Vérifier la sortie avant de dépendre d’un service

Définir ce qui doit rester utilisable

La propriété du code source est précieuse. Ce n’est qu’une partie du plan de sortie.

Prenons une application fictive dont le code se trouve dans le dépôt de l’entreprise. Le build télécharge un package privé du fournisseur. La production utilise un compte cloud appartenant au fournisseur. Personne n’a consigné la procédure de restauration de la base.

L’entreprise possède le code, mais ne peut pas encore exploiter le service seule. Son plan de sortie doit couvrir ensemble droits, actifs, accès et connaissances.

Inventorier les dépendances

Vérifiez les formats et le périmètre des exports. Un export documentaire lisible ne préserve pas nécessairement toutes les relations, pièces jointes ou traces d’exécution. Demandez un exemple et examinez-le avec les personnes qui l’utiliseront.

Réaliser une reconstruction indépendante

Utilisez un environnement de test sûr et des données d’exemple approuvées. Remettez le dossier de transfert proposé à un ingénieur autorisé. Demandez-lui de construire l’application, d’appliquer la configuration, de restaurer les données et de vérifier une opération métier complète.

Consignez chaque élément manquant et le délai pour l’obtenir. Évitez de fournir discrètement des connaissances non documentées pendant l’exercice. Le but est de découvrir ce qui manquerait à la prochaine équipe.

Examinez ensuite les contraintes de transition : abonnements qui se chevauchent, durée de transfert des données, accès aux packages, changements d’identité et disponibilité du support. Incluez ces coûts dans la comparaison entre construire et acheter.

Séparer export et suppression

L’export produit une copie. La transition change qui exploite le service. La suppression retire des enregistrements définis selon la procédure convenue. Ce sont des décisions distinctes, avec des preuves différentes.

Définissez le périmètre de conservation et de suppression requis avec les responsables concernés. Confirmez les conditions et procédures actuelles du fournisseur. Ne supprimez pas l’unique copie de reprise utilisable avant d’avoir vérifié le système destinataire.

Taiga documente une procédure d’export administratif et une procédure d’effacement distincte. Les valeurs des secrets sont exclues de l’export. Le transfert nécessite donc un moyen autorisé de recréer les secrets requis. Vérifiez le contenu actuel de l’export au regard de vos besoins de transition ; ne supposez pas qu’il constitue une sauvegarde complète de l’application.

Décider quelles dépendances sont acceptables

La portabilité n’exige pas de supprimer tous les services managés. Une dépendance peut être un choix raisonnable si sa valeur, ses contraintes et son parcours de transition sont compris.

Consignez les dépendances acceptées, un responsable et un déclencheur de réexamen. Répétez l’exercice de sortie après un changement important d’architecture ou de contrat. Poursuivez avec un plan d’adoption qui inclut ces responsabilités dès le départ.