I progetti con codice sorgente esportato richiedono un test di portabilità

Esportare il codice sorgente prova che hai ricevuto dei file. Non prova che il progetto possa compilare, avviarsi, autenticare gli utenti, leggere i dati di produzione o essere distribuito dopo la scomparsa del builder di app IA originale. Considera la portabilità un test di accettazione, non una casella da spuntare in un contratto commerciale.

Ho ereditato abbastanza applicazioni generate da diffidare di un repository pulito a prima vista. I guasti costosi di solito si nascondono fuori dal codice dell'applicazione più evidente: una richiesta in esecuzione a un servizio del fornitore, un callback di autenticazione registrato nel tenant di qualcun altro, una policy del database mai entrata nel controllo versione, oppure un'impostazione di deployment che esiste solo in una dashboard gestita. Un progetto è portabile soltanto quando il tuo team può riprodurne il comportamento funzionante partendo dall'esportazione e dai servizi esterni documentati, usando account sotto il proprio controllo.

I progetti con codice esportato possono dipendere ancora dal builder

Un progetto con codice esportato funziona in modo indipendente solo se ogni dipendenza necessaria in fase di build e di esecuzione è disponibile, documentata, trasferibile e concessa in licenza per l'uso fuori dal builder. Questa definizione è più rigorosa di «il repository compila». Copre il percorso da una macchina vuota a una release di produzione funzionante, inclusi identità, dati, attività pianificate, segreti, regole di rete e ripristino.

Tre affermazioni diverse spesso vengono confuse. L'accesso al codice significa che puoi ispezionare i file. L'indipendenza della build significa che puoi produrre artefatti senza chiamare il builder. L'indipendenza in esecuzione significa che quegli artefatti continuano a gestire richieste reali senza il builder. Un fornitore può soddisfare la prima affermazione e non le altre due.

La distinzione ha una conseguenza diretta sul contratto. Se il contratto promette «esportazione del codice sorgente», potresti ricevere una directory React, un manifest dei pacchetti e un README, pur avendo ancora bisogno di un SDK proprietario o di un gateway ospitato. Chiedi invece un risultato operativo: un tecnico autorizzato deve poter compilare ed eseguire la release accettata in un ambiente pulito usando account di proprietà del cliente.

Definisci il perimetro prima del test. I servizi gestiti non implicano automaticamente un problema di portabilità. La maggior parte delle applicazioni serie dipende da un cloud, un gestore di pagamenti, un fornitore email o un servizio di identità. Il punto è sapere di aver scelto quelle dipendenze e poterle spostare o sostituire con un proprio contratto. Un servizio nascosto del fornitore che non puoi acquistare separatamente è diverso da un database PostgreSQL documentato nel tuo account cloud.

Crea un registro delle dipendenze con quattro campi per ogni componente esterno: proprietario, scopo, percorso di sostituzione e comportamento in caso di errore. Per «proprietario» si intende il titolare legale dell'account, non chi conosce la password. Il «percorso di sostituzione» può essere una procedura di migrazione, un'interfaccia che puoi reimplementare oppure la decisione esplicita di mantenere il servizio. Il «comportamento in caso di errore» registra ciò che vedono gli utenti quando non è disponibile. Se il venditore non sa compilare questi campi, l'esportazione non è stata spiegata abbastanza bene da poterne stimare il rischio.

Il miglior primo test è banale: disconnetti l'accesso all'account del builder e prova l'applicazione. Revoca i token in una copia di staging, blocca i suoi domini noti al confine della rete e osserva cosa si rompe. Non iniziare leggendo ogni file. Le prove in esecuzione trovano dipendenze che la revisione del codice non vede, comprese configurazioni iniettate e chiamate effettuate da pacchetti compilati.

Traccia l'applicazione mentre esegue flussi reali

I callback in esecuzione emergono quando osservi DNS, connessioni in uscita, richieste del browser e job in background durante flussi rappresentativi. Una home page che si carica dimostra poco. Prova accesso, recupero password, caricamento file, ricerca, passaggi di fatturazione, consegna email, attività pianificate, azioni amministrative e qualunque funzione basata sull'IA che il prodotto vende davvero.

Esegui l'applicazione in una rete di staging nuova in cui il traffico in uscita è registrato. Concedile solo le destinazioni elencate nel registro delle dipendenze. Se l'ambiente lo consente, inizia con una policy di blocco per il traffico non elencato. Ogni richiesta bloccata apre una domanda: è necessaria, telemetria facoltativa, un controllo degli aggiornamenti o una chiamata non documentata al piano di controllo?

Gli strumenti per sviluppatori del browser sono importanti perché alcune dipendenze non toccano mai il tuo server. Ispeziona il pannello Rete dopo aver cancellato lo spazio di archiviazione e usato una nuova sessione. Osserva host delle richieste, richieste preflight fallite, connessioni WebSocket, script caricati e reindirizzamenti. Un frontend può chiamare direttamente un'API del builder anche quando il repository del server sembra autosufficiente. Anche i service worker possono conservare il vecchio comportamento, quindi annullane la registrazione prima di ripetere il test.

In un albero sorgente simile a Unix, questa ricerca fornisce un primo inventario utile:

grep -R -n -E 'https?:|wss?:|fetch[(]|axios|WebSocket|grpc|callback|webhook' .

Aspettati un output nel formato path/to/file:line:matching text. Esamina i lockfile generati separatamente dal codice dell'applicazione, perché un dominio nei metadati di un pacchetto non prova una chiamata in esecuzione. Al contrario, una ricerca pulita non prova l'indipendenza: le variabili d'ambiente possono comporre gli host, gli alias DNS possono nasconderli e le dipendenze binarie possono effettuare richieste proprie.

Cerca in passaggi separati termini del fornitore, importazioni di SDK e prefissi delle variabili d'ambiente. Poi ispeziona i lockfile per capire se i pacchetti arrivano da un registro pubblico o da un registro privato del fornitore. Il successo ottenuto dalla cache può ingannarti. Elimina le cache dei pacchetti del linguaggio nell'ambiente di test isolato e ricompila usando solo le credenziali documentate per il registro.

Traccia il comportamento in background abbastanza a lungo da superare un ciclo dello scheduler. Un processo web può sembrare sano mentre i consumer delle code falliscono, i report pianificati si fermano e i tentativi dei webhook si accumulano. Attiva i job manualmente quando attendere la normale pianificazione rallenterebbe il test. Registra destinazione, metodo di richiesta, tipo di autenticazione, classe di risposta, regola di ritentativo e conseguenza visibile all'utente per ogni integrazione in uscita.

Non accettare «quel callback è solo telemetria» senza testarne il guasto. Bloccalo e ripeti il flusso. La telemetria facoltativa dovrebbe scadere rapidamente o fallire senza modificare l'operazione dell'utente. Ho visto chiamate di logging dentro una transazione di richiesta trasformare un innocuo guasto dell'analisi in un salvataggio fallito. L'etichetta non determina il rischio, lo determina il percorso del codice.

Gli SDK proprietari richiedono un percorso di rimozione o licenza

Un SDK proprietario è accettabile solo quando puoi ottenerlo, compilare con esso, usarlo legalmente e sostituirlo secondo tempi tollerabili per l'azienda. Avere nell'esportazione il codice del suo wrapper non concede i diritti sull'SDK, sul protocollo, sull'endpoint ospitato o sul modello che lo sostiene.

Fai l'inventario delle dipendenze sia dai manifest sia dalle importazioni del codice. Per JavaScript, ispeziona package.json e il lockfile. Per Go, ispeziona go.mod e i checksum. Per Flutter, ispeziona pubspec.yaml e il lockfile. Annota i pacchetti recuperati da repository Git, registri privati, percorsi locali o archivi. Sono luoghi frequenti in cui si nascondono componenti di proprietà del builder.

Per ogni pacchetto dubbio, rispondi a quattro domande concrete:

1. Un nuovo agente di build di proprietà del cliente può scaricare la versione esatta?
2. La licenza consente l'uso in produzione dopo la fine del contratto con il builder?
3. Il pacchetto chiama un servizio che il cliente può acquistare direttamente?
4. L'interfaccia è abbastanza piccola da poter essere sostituita, ed è testata?

Esegui una build a freddo con credenziali create in un'organizzazione di proprietà del cliente. Non copiare l'intera directory di configurazione di uno sviluppatore nella macchina di test. Importeresti pacchetti in cache, impostazioni implicite del registro e token personali, vanificando l'esercizio. Una procedura di build corretta parte dalla versione documentata della toolchain e dichiara ogni credenziale aggiuntiva separatamente.

Genera una distinta base del software se la toolchain lo supporta, ma non confondere quel documento con un verdetto sulla portabilità. Una SBOM elenca i componenti, raramente indica chi controlla un account remoto o se un pacchetto contatta un servizio esterno. Usala per confrontare ciò che dichiara il repository con ciò che contiene l'artefatto compilato.

Quando un client proprietario è dietro un adapter ristretto, scrivi subito un test contrattuale sull'adapter. Forniscigli una richiesta nota, verifica la risposta normalizzata e ripeti il test con l'endpoint di rete bloccato. Il fallimento deve essere esplicito e circoscritto. Se le chiamate proprietarie compaiono in componenti di visualizzazione, gestori di route e modelli di dati, valuta il costo di un refactoring prima di firmare. Il problema cresce con il numero di punti di chiamata e l'accoppiamento semantico, non con il numero di righe dell'SDK.

I team spesso consigliano di sostituire ogni dipendenza proprietaria prima dell'acquisto. Sembra prudente, ma può sprecare settimane su servizi che l'acquirente intende mantenere. La regola migliore è rimuovere le dipendenze non disponibili o non acquistabili direttamente, isolare quelle accettate e associare il costo di migrazione alle altre. La portabilità è controllo delle scelte, non un'applicazione priva di servizi esterni.

L'autenticazione riguarda più del solo albero sorgente

L'autenticazione si trasferisce senza problemi solo quando il cliente controlla il tenant di identità, le registrazioni dei reindirizzamenti, le chiavi di firma, gli identificativi utente, i modelli email e il processo di recupero. Il codice dell'applicazione cattura di solito una sola parte di questo sistema.

Inizia disegnando il percorso di accesso come una serie di passaggi reali. Il browser raggiunge l'applicazione, l'applicazione reindirizza a un provider di identità, il provider torna a un callback registrato e il backend scambia o convalida le credenziali. Registra proprietario e posizione della configurazione a ogni passaggio. Se una console è accessibile solo tramite l'organizzazione del builder, richiedi il trasferimento o la sostituzione prima dell'accettazione.

L'autenticazione gestita crea un problema di dati particolarmente scomodo. La tabella utenti dell'applicazione può memorizzare un subject specifico del provider invece di un indirizzo email o di un ID interno stabile. Esportare le righe non aiuta se un nuovo tenant di identità emette subject diversi. Testa l'associazione degli account, la gestione dei duplicati, gli utenti con password, quelli con accesso social, l'iscrizione all'autenticazione a più fattori, gli account bloccati e gli utenti che hanno cambiato indirizzo email.

OpenID Connect definisce il claim sub come un identificativo localmente univoco e mai riassegnato nell'ambito dell'emittente. L'emittente conta. Considerare il solo sub come portabile a livello globale può collegare il record applicativo sbagliato dopo un cambio di tenant. Memorizza e confronta l'emittente insieme al subject, poi progetta una mappatura esplicita per la migrazione.

Il test richiede almeno quattro account: un utente normale, un amministratore, un utente disabilitato e un utente con un secondo fattore di autenticazione. Sposta o ricrea la configurazione di identità in un tenant di proprietà del cliente, ripristina una copia del database di staging e verifica sia l'accesso riuscito sia quello negato. Prova anche disconnessione, rinnovo dei token, reimpostazione password, accettazione dell'invito e scadenza della sessione. I team ricordano il percorso di accesso riuscito e scoprono il recupero non funzionante solo dopo il passaggio.

Cerca nel repository URI di reindirizzamento, ID client, nomi dell'emittente, domini dei cookie, valori audience e riferimenti alle chiavi di firma. Tieni i segreti fuori dal repository, ma documenta nelle istruzioni di deployment nomi, proprietari, procedure di creazione e rotazione, e formati richiesti. Un file di ambiente di esempio dovrebbe identificare il contratto senza contenere valori reali:

AUTH_ISSUER=
AUTH_CLIENT_ID=
AUTH_CLIENT_SECRET=
AUTH_CALLBACK_ORIGIN=
SESSION_SIGNING_KEY=

Non accettare un tenant condiviso del builder come accordo permanente solo perché la migrazione può avvenire «più tardi». Le migrazioni dell'identità coinvolgono ogni utente attivo e ogni presupposto di autorizzazione. Trasferisci il controllo prima della firma oppure rendi la sostituzione una condizione dell'accordo con costo e test definiti.

La portabilità del database include comportamento e operazioni

Un dump del database non basta quando schemi, estensioni, policy a livello di riga, trigger, archiviazione degli oggetti, code, backup e regole di connessione vivono al di fuori di esso. La portabilità del database significa poter ripristinare i dati e riprodurre il comportamento che li protegge e modifica.

Inizia con un'istanza PostgreSQL vuota, di proprietà del cliente, alla versione principale documentata. Applica in ordine le migrazioni del repository. Se il progetto non ha migrazioni e richiede l'importazione di un dump dello schema creato dal fornitore, registralo come difetto. Un dump può catturare lo stato di oggi, ma non spiega come la release successiva modifichi quello stato in sicurezza.

Confronta lo schema ripristinato con produzione o staging. Controlla tabelle, colonne, tipi, vincoli, indici, sequenze, viste, funzioni, trigger, estensioni abilitate, ruoli, autorizzazioni e policy di sicurezza a livello di riga. Molti strumenti di migrazione omettono ruoli e impostazioni a livello di provider. Un'applicazione può superare i test di lettura di base mentre i job amministrativi falliscono perché il ruolo ripristinato non ha i permessi su una sequenza o una funzione.

Poi verifica il percorso dei dati con un ciclo controllato:

1. Crea un record tramite il flusso pubblico dell'applicazione.
2. Leggilo tramite un secondo utente autorizzato, quando è previsto che venga condiviso.
3. Conferma che un utente non autorizzato non possa leggerlo né modificarlo.
4. Aggiornalo ed eliminalo tramite l'applicazione.
5. Ripristina il database in un'altra istanza pulita e ripeti le letture.

Questa sequenza testa insieme il codice dell'applicazione, la policy di autorizzazione, i valori generati e la recuperabilità. I semplici conteggi di righe con SQL diretto non possono coprire questi comportamenti.

Considera l'archiviazione degli oggetti parte del perimetro del database quando le righe puntano a file caricati. Esporta bucket, metadati degli oggetti, regole di accesso, regole del ciclo di vita e impostazioni di generazione degli URL. Un database ripristinato pieno di chiavi di oggetti è inutile se i file sottostanti restano in un bucket di proprietà del builder. Lo stesso avvertimento vale per indici di ricerca e archivi vettoriali: decidi se migrarli o ricostruirli e dimostra la procedura di ricostruzione.

Non misurare successo o fallimento con un unico dump piccolo. Usa una copia delle dimensioni dello staging che contenga testi lunghi, valori null, caratteri non ASCII, oggetti grandi, timestamp vicini ai cambi dell'ora legale e relazioni rappresentative. Non servono benchmark inventati. Servono prove che il trasferimento termini entro l'interruzione consentita e che l'applicazione funzioni dopo.

Le affermazioni sui backup richiedono un ripristino. Identifica chi pianifica i backup, dove vengono conservate le copie, chi può decrittarle, come funziona la conservazione e come rilevi un backup fallito. Ripristinane uno in un account isolato seguendo istruzioni scritte. Se solo il builder può premere il pulsante di ripristino, hai una funzione di servizio, non un piano di recupero indipendente.

Una pipeline CI mancante è conoscenza del prodotto mancante

Un repository esportato senza integrazione continua riproducibile lascia all'acquirente il compito di riscoprire versioni degli strumenti, ordine di build, test, pacchettizzazione degli artefatti, tempi delle migrazioni del database e controlli di rilascio. Questa conoscenza fa parte della consegna anche quando la pipeline interna del venditore non può essere trasferita letteralmente.

Cerca definizioni della pipeline, file di build dei container, file con le versioni degli strumenti, comandi di test, regole di lint, comandi di migrazione e definizioni dell'infrastruttura. Poi confrontali con un log di deployment reale. La documentazione spesso descrive una semplice build web mentre la piattaforma gestita genera silenziosamente configurazione, inietta un componente server, compila un bundle mobile oppure esegue migrazioni del database.

Ricostruisci la pipeline minima in un account CI di proprietà del cliente. Dovrebbe eseguire il checkout di una revisione fissata, installare una toolchain dichiarata, recuperare le dipendenze, eseguire i test, produrre artefatti immutabili e registrarne l'identità. Durante il test il deployment può restare manuale, ma l'artefatto che raggiunge lo staging deve essere quello prodotto dalla pipeline.

Un registro di accettazione compatto può avere questa forma:

revision: 4f2c9ab
toolchain: declared versions loaded
dependencies: cold install passed
tests: unit and integration passed
artifacts: web, server, mobile
migrations: dry run passed
staging: health and workflow checks passed

I valori varieranno, ma ogni riga richiede un output automatico o un record interno collegato, non il ricordo di una persona. Conserva il registro con le prove di accettazione.

Non pretendere la segreta infrastruttura di deployment del venditore se non ti serve. Pretendi istruzioni e configurazione sufficienti per riprodurre il risultato. Una pipeline portabile può usare un prodotto CI diverso purché esegua le stesse fasi necessarie e non indebolisca i controlli di rilascio.

Le applicazioni mobile aggiungono risorse di firma, identificativi del pacchetto, account degli store e credenziali per le notifiche push. È facile trascurarle perché una build del codice può funzionare in un emulatore senza di esse. Verifica che il cliente possieda gli account di distribuzione e documenta la rotazione dei certificati. Per le applicazioni server e web, includi nella prova di rilascio la verifica del dominio, l'emissione del certificato TLS, le modifiche DNS e l'invalidazione della cache.

Il test della pipeline termina con una modifica, non con la ricompilazione del commit fornito. Fai una modifica visibile ma innocua, aggiungi una migrazione del database annullabile, compilala, distribuiscila in staging, verificala ed esegui il rollback. Così scopri gli artefatti generati che sono stati inclusi una volta nel repository ma non possono essere rigenerati.

Fissa le versioni dei pacchetti del sistema operativo usati dalla build oltre alla toolchain del linguaggio. I moduli nativi possono compilare con librerie presenti per caso nell'immagine del builder. Un nuovo runner allora fallisce prima dell'avvio dei test dell'applicazione o, peggio, produce un artefatto con comportamento diverso. Acquisisci nomi e versioni dei pacchetti in una definizione di container o in una descrizione della build equivalente e leggibile dalle macchine.

Tieni i segreti fuori dai log CI dimostrando al tempo stesso che la pipeline può ottenerli da un archivio controllato dal cliente. Il test dovrebbe creare una credenziale di staging a breve durata, iniettarla con il meccanismo documentato e ruotarla senza modificare il codice. Se un segreto deve essere incollato in una dashboard del fornitore dal personale di supporto, registra quella dipendenza invece di nasconderla nelle note di configurazione.

Le ipotesi sull'hosting emergono durante un deployment in ambiente pulito

Un deployment in ambiente pulito dimostra la portabilità quando un team che non conosce il builder può avviare il sistema in un ambiente di proprietà del cliente usando solo l'esportazione, i servizi dichiarati e le istruzioni scritte. Eseguilo prima dell'accettazione contrattuale, con un limite di tempo e un registro dei problemi.

Scegli un ambiente che corrisponda al modello operativo previsto. Passare da una piattaforma gestita a macchine virtuali semplici crea lavoro estraneo e può far sembrare guasto un progetto portabile. Riproduci le primitive necessarie, come container, PostgreSQL, archiviazione degli oggetti, job pianificati, segreti e bilanciamento del carico, senza ricreare la magia non documentata del fornitore.

Ispeziona l'applicazione per individuare presupposti su dischi locali scrivibili, porte fisse, sessioni persistenti, intestazioni proxy attendibili, nomi di regione, hostname iniettati e variabili d'ambiente specifiche della piattaforma. La Twelve-Factor App raccomanda di conservare la configurazione nell'ambiente e di trattare i servizi di supporto come risorse collegate. Queste idee restano utili, ma le sole variabili d'ambiente non documentano proprietà, formati o creazione. Associa ogni variabile a un record operativo.

I controlli di integrità meritano test diretti. Un processo che restituisce successo prima che finiscano le migrazioni o prima che si colleghino le dipendenze necessarie può entrare in un ciclo di riavvio dietro un orchestratore. Se il sistema di hosting lo supporta, separa liveness e readiness. Ferma database, object store e coda uno alla volta, poi osserva codici di stato, log, comportamento dei tentativi e recupero al ritorno del servizio.

Conferma come l'applicazione gestisce più istanze. Sessioni in memoria, directory locali per gli upload e blocchi dei job locali al processo funzionano su una sola istanza gestita e falliscono dopo la scalabilità. Avvia due istanze, invia le richieste dello stesso utente a entrambe ed esegui worker concorrenti. Verifica che le sessioni persistano, i file restino disponibili e un'attività pianificata non venga eseguita due volte, a meno che non sia progettata per essere idempotente.

Osserva l'arresto con la stessa attenzione dell'avvio. Invia un segnale di terminazione mentre richieste e job in background sono attivi. Il processo dovrebbe smettere di accettare nuovo lavoro, completare o restituire in sicurezza i job acquisiti, chiudere le connessioni e terminare entro il periodo di tolleranza dell'host. Un builder gestito potrebbe aver nascosto arresti improvvisi con timeout o tentativi lunghi che il tuo nuovo host non condivide.

Anche log e metriche portano con sé ipotesi sull'hosting. Conferma che l'applicazione scriva eventi strutturati in una destinazione documentata, rimuova segreti e dati personali quando necessario e esponga informazioni sufficienti per diagnosticare un flusso fallito. Una dashboard proprietaria è facoltativa solo quando l'output standard o un altro destinatario controllato dal cliente conserva le prove necessarie.

Le affermazioni su regione e posizione dei dati richiedono prove di configurazione. Registra dove vengono eseguiti applicazione, database, backup, log e archiviazione degli oggetti, oltre ai servizi esterni che ricevono dati. Un selettore di regione per il processo web non mantiene i dati in un paese se autenticazione o analisi li inviano altrove. Il contratto dovrebbe indicare chi approva i cambiamenti di queste posizioni.

Koder.ai supporta esportazione del codice, deployment e hosting, domini personalizzati, snapshot e rollback. Se valuti un progetto Koder.ai esportato per un funzionamento indipendente, applica lo stesso standard di ambiente pulito: testa i componenti React, Go con PostgreSQL o Flutter esportati nell'ambiente che intendi possedere e documenta ogni servizio che scegli di mantenere.

Inserisci condizioni di superamento e fallimento nel contratto

Il contratto dovrebbe definire la portabilità come comportamento osservato, elencare l'ambiente di accettazione, assegnare la responsabilità della correzione e conservare tempo sufficiente per risolvere i problemi prima del pagamento finale o del vincolo. Un linguaggio vago sulla proprietà non salverà un'applicazione che nessun altro riesce a distribuire.

Allega una matrice di accettazione invece di affidarti a un paragrafo intitolato «codice sorgente». Ogni riga dovrebbe indicare una capacità, la procedura di test, il risultato atteso, le prove, la parte responsabile e la gravità. Copri build a freddo, chiamate di rete in esecuzione, trasferimento dell'identità, ripristino del database, archiviazione file, lavoro in background, CI, deployment pulito, monitoraggio, ripristino del backup, una piccola modifica e rollback.

Usa criteri di superamento osservabili da terzi. «Nessuna dipendenza proprietaria critica» invita alla discussione. «L'applicazione di staging completa i flussi da A a F mentre tutte le credenziali di proprietà del builder sono revocate e i domini del builder sono bloccati» è verificabile. Definisci per nome le dipendenze consentite e il proprietario dell'account, così il team non scambierà un servizio gestito approvato per un fallimento.

Richiedi la consegna del codice e dei materiali operativi a una revisione fissata: lockfile, migrazioni, definizioni di build, configurazione dell'infrastruttura ove disponibile, catalogo delle variabili d'ambiente, registro delle dipendenze, esportazione dei dati, piano di migrazione dell'identità, runbook, avvisi di licenza e risorse di firma o distribuzione appartenenti al cliente. Registra esplicitamente le esclusioni. Il silenzio non dovrebbe significare accettazione.

Definisci la gravità in base all'effetto sull'azienda. La mancanza di un evento facoltativo di analisi non equivale a un'interruzione dell'accesso. Uno schema utile distingue i blocchi che impediscono la build o i flussi principali, i difetti gravi che eliminano una capacità importante o un percorso di recupero e i difetti minori con una soluzione alternativa documentata. Collega date di accettazione e correzione a questi livelli senza inventare una tempistica universale.

Definisci anche i dati di test e chi esegue il test. A volte i venditori dimostrano la portabilità con un database vuoto e un account amministratore che aggira l'autorizzazione ordinaria. Richiedi utenti, ruoli, file e job in background rappresentativi, con il personale del cliente che esegue la procedura documentata. Mantieni sintetici i segreti, ma rendi realistici relazioni e casi limite.

I costi fanno parte del pacchetto di prove. Registra i servizi fatturati separatamente necessari per eseguire la release esportata e qualunque piano minimo, costo di uscita dei dati o abbonamento a un registro privato identificato dal venditore. Il test non deve prevedere ogni fattura futura. Deve impedire che un'esportazione apparentemente indipendente riveli un contratto obbligatorio con il fornitore solo dopo la firma.

Includi obblighi di collaborazione per i servizi che non possono essere trasferiti immediatamente. Il venditore potrebbe dover ruotare chiavi, approvare un'esportazione dell'identità, spostare un dominio o fornire un'istantanea finale dei dati. Indica l'azione e la persona responsabile. «Assistenza ragionevole» è difficile da far rispettare quando la produzione è ferma.

Conserva il diritto di ripetere i test dopo le correzioni e dopo l'esportazione finale. I progetti generati cambiano rapidamente e una correzione dimostrata sulla revisione del mese scorso non dice nulla sulle nuove dipendenze aggiunte ieri. Fissa il commit testato e gli hash degli artefatti nel record di accettazione.

Non lasciare che una clausola di escrow sostituisca questo lavoro. L'escrow può consegnare file dopo un evento che lo attiva, ma file senza istruzioni di build aggiornate, proprietà delle credenziali e percorsi di recupero testati potrebbero arrivare troppo tardi per essere utili. L'indipendenza operativa deve esistere mentre entrambe le parti possono ancora collaborare.

Firma quando un secondo team può compilare, eseguire, modificare, distribuire e ripristinare la release accettata senza aiuto privilegiato del builder originale. Qualunque cosa in meno è possesso del codice sorgente con un progetto di migrazione irrisolto allegato, e il prezzo del contratto dovrebbe riflettere quel lavoro.