Quando dovresti migrare un'app vibe-coded?

Spostare un'app generata prima del lancio costa meno ed è più lineare. Farlo dopo aver acquisito utenti offre più elementi per decidere, ma lascia molto meno margine di errore. Il momento giusto dipende meno dal fatto che il progetto sia nato in Lovable, Bolt, v0 o Replit e più dalla tua capacità di elencare e provare ogni confine con stato gestito dalla piattaforma attuale.

Considero il lancio il momento in cui identità, dati e dominio pubblico diventano promesse agli utenti. Prima, una migrazione non riuscita costa tempo di sviluppo. Dopo, lo stesso errore può bloccare i clienti, perdere scritture, invalidare sessioni o inviare traffico a due versioni del prodotto. La crescita mostra cosa merita di essere conservato, ma trasforma un normale spostamento di codice in un cambiamento operativo.

Non decidere in base alla dimensione dell'albero dei sorgenti. Una piccola app con autenticazione gestita e database attivo può essere più difficile da spostare di un grande sito statico. Decidi in base alla proprietà: chi controlla repository, identità utente, database, segreti, file, lavori pianificati, dominio, distribuzione e percorso di rollback?

Prima del lancio, la migrazione compra libertà

Migrare prima del lancio è di solito la scelta migliore quando la piattaforma attuale non soddisfa un requisito noto di proprietà, distribuzione, posizione dei dati o manutenibilità. Hai ancora spazio per cambiare schemi, sostituire l'autenticazione, rinominare variabili d'ambiente e azzerare dati di test senza dover negoziare con gli utenti.

Questa fase è particolarmente adatta quando l'app ha solo account seed e record eliminabili. Puoi esportare il codice, compilarlo in un ambiente pulito, ricreare il database dalle migrazioni e scoprire quali parti erano implicite nello spazio di lavoro originale. Ogni errore è utile perché rivela una dipendenza prima che trasporti dati dei clienti.

Il momento economico non rende il lavoro facoltativo. I progetti generati spesso funzionano perché la piattaforma originale inserisce configurazione, fornisce un URL del database, ospita funzioni o conosce una convenzione di build. L'esportazione dei sorgenti dimostra che possiedi i file. Non dimostra che un altro host possa compilare ed eseguire lo stesso sistema.

Prima del lancio, pretendo un test in ambiente pulito. Un collega che non ha creato il progetto riceve solo il repository, un elenco scritto dei segreti con valori di sviluppo sicuri e le istruzioni di configurazione. Se non riesce ad accedere, creare un record e completare il percorso utente principale, il progetto non è ancora portabile.

Ci sono anche buoni motivi per rimandare. Un prototipo iniziale può cambiare modello dati ogni giorno e il lavoro di migrazione può diventare inutile con la prossima decisione di prodotto. Se la piattaforma attuale supporta il lancio previsto, l'esportazione dei sorgenti, la distribuzione, i domini personalizzati e un percorso di rollback credibile, imparare da una piccola release può valere più che rifinire l'infrastruttura di un prodotto che nessuno desidera.

La decisione prima del lancio quindi non è «Possiamo spostarci?». È «Lo spostamento elimina un rischio noto per il lancio, oppure stiamo pagando per conservare ipotesi?». Migra per un vincolo concreto. Non farlo solo perché un'infrastruttura convenzionale sembra più rispettabile.

Dopo la crescita, le prove comportano obblighi

Migrare dopo aver acquisito utenti ha senso quando l'uso reale ha evidenziato esigenze che la configurazione originale non può soddisfare, ma il piano deve mantenere ogni promessa pubblica già in uso. Ora conosci i percorsi più frequentati, il volume reale dei dati, i lavori in background attivati dagli utenti e le integrazioni importanti. Queste informazioni possono evitare una costosa migrazione verso un'architettura immaginaria.

Anche gli obblighi sono concreti. Le password esistenti devono continuare a funzionare oppure gli utenti devono avere un percorso di reimpostazione controllato. Gli identificatori del database devono restare stabili se URL, fatture, webhook o chiavi esterne li espongono. I file caricati richiedono un piano di trasferimento. I link email e i callback OAuth devono puntare al dominio corretto. Le scritture effettuate durante la copia devono arrivare al nuovo database oppure essere sospese deliberatamente.

La crescita non è una soglia unica. Dieci clienti attivi che usano l'app per le buste paga creano più rischio di migrazione di diecimila lettori di un catalogo statico. Conta stato e conseguenze, non gli account. Chiediti quanti dati cambiano al minuto, quanto costa un'azione duplicata, quanto rapidamente l'assistenza può raggiungere ogni utente coinvolto e se l'azienda può tollerare una finestra di manutenzione.

È anche la fase in cui i team confondono la domanda osservata con il permesso di cambiare architettura. Più utenti non giustificano automaticamente una riscrittura. Se l'applicazione esportata è comprensibile e i servizi attuali possono essere separati un confine alla volta, una migrazione incrementale è più sicura della sostituzione dell'intero stack.

Voglio una mappa scritta della proprietà prima di approvare uno spostamento dopo la crescita:

• Repository dei sorgenti e processo di build
• Directory utenti e sessioni attive
• Database primario, file e backup
• Segreti, lavori pianificati e webhook in uscita
• Dominio, record del mittente email, monitoraggio e autorità di rollback

Ogni voce vuota blocca il passaggio, non è un dettaglio da risolvere la notte del cutover. Il nome della piattaforma conta solo quando cambia il modo di esportare o riconfigurare una di queste risorse.

L'autenticazione è una migrazione di identità

L'autenticazione va trattata come trasferimento di identità e regole di fiducia, non come una schermata di accesso da ricreare più tardi. Il modulo visibile è la parte facile. Hash delle password, ID soggetto del provider, stato email verificata, iscrizione al multifattore, metodi di recupero, sessioni e ruoli di autorizzazione custodiscono la vera continuità.

Per prima cosa, stabilisci se l'app possiede una tabella utenti o delega l'identità a un servizio gestito. Se puoi esportare gli utenti, controlla i campi disponibili e se gli hash delle password possono essere importati nella destinazione. Gli hash non sono intercambiabili solo perché entrambi i sistemi li chiamano hash. La destinazione deve supportare algoritmo e parametri esatti, oppure ogni password richiede un reset.

L'accesso social crea un altro punto delicato dell'identità. I provider OAuth restituiscono di solito un identificatore stabile specifico del provider. Se la nuova implementazione associa gli account solo per email, può unire erroneamente persone quando l'indirizzo cambia o i provider restituiscono alias diversi. Conserva la tripla formata da emittente, soggetto del provider e ID utente locale. Registra di nuovo gli URL di callback prima del passaggio, poi prova sia un nuovo accesso sia un account esistente.

La Session Management Cheat Sheet di OWASP consiglia di rinnovare l'identificatore di sessione dopo un cambio di privilegi. Una migrazione non è di per sé un cambio di privilegi, ma il consiglio mostra un confine importante: lo stato di sessione è stato di sicurezza. Cercare di serializzare cookie opachi da uno stack di autenticazione a un altro è quasi sempre un cattivo affare. Mantieni temporaneamente il vecchio verificatore se lo comprendi pienamente, oppure fai scadere le sessioni e informa gli utenti che dovranno accedere di nuovo. Non accettare mai silenziosamente un cookie che il nuovo servizio non può convalidare.

L'ambito dei cookie può compromettere uno spostamento altrimenti corretto. Controlla nome del cookie, dominio, percorso e attributi Secure, HttpOnly e SameSite prodotti dal nuovo host. Il riferimento Set-Cookie di MDN spiega che un cookie con attributo Domain è disponibile per quel dominio e i suoi sottodomini, mentre l'assenza del dominio lo restringe all'host che lo ha impostato. La distinzione conta quando la vecchia app usava un host per l'interfaccia web e un altro per l'API. Prova con un profilo browser nuovo, così un vecchio cookie non può far sembrare sano il nuovo flusso.

L'autorizzazione merita un confronto separato. Un utente può autenticarsi con successo ma perdere appartenenza a un'organizzazione, ruolo amministratore, diritto a un abbonamento o policy a livello di riga. Esporta un campione di account con ruoli diversi e scrivi test di accesso atteso prima di spostare i dati. Una pagina di accesso riuscito non dimostra quasi nulla.

Per una migrazione prima del lancio, preferisco sostituire ora il sistema di identità ed eliminare gli utenti di test. Dopo la crescita, scegli una strategia di continuità esplicita:

• Importa hash delle password compatibili e conserva gli ID del provider.
• Mantieni il vecchio servizio di identità mentre l'app si sposta.
• Richiedi un reset con token monouso in scadenza.
• Esegui un breve ponte di doppia lettura con una sola autorità per le scritture.

Non gestire due directory utenti scrivibili. Modifiche email in conflitto e richieste di eliminazione dell'account trasformeranno quella comodità in un incidente.

Il trasferimento del database deve conservare il significato

Una migrazione di database riesce solo quando la destinazione conserva vincoli, identificatori, timestamp, relazioni e ogni scrittura accettata durante il passaggio. Il conteggio delle righe è una verifica debole. Due database possono avere lo stesso numero di righe e divergere su precisione monetaria, fusi orari, unicità, gestione dei null o chiavi esterne.

Prima del lancio, ricostruisci il database da migrazioni versionate invece di copiare un database di sviluppo. Inserisci solo i record necessari all'applicazione. Questo test dimostra che la cronologia dello schema è completa e che l'app non dipende da tabelle create manualmente da qualcuno in una console ospitata.

Dopo la crescita, separa lo spostamento dello schema da quello dei dati attivi. Registra motore e versione di origine, estensioni, regole di confronto, colonne generate, trigger, policy a livello di riga, sequenze e oggetti di grandi dimensioni. Se la destinazione usa un motore di database diverso, trattalo anche come migrazione dell'applicazione. La sintassi SQL è la parte minore del cambiamento: comportamento delle transazioni e semantica dei tipi generano le sorprese più spiacevoli.

La documentazione PostgreSQL descrive pg_dump come un'esportazione coerente che non blocca lettori o scrittori. È utile, ma spesso i team interpretano troppo questa promessa. Uno snapshot coerente non include le scritture confermate dopo l'inizio dello snapshot. Ti serve comunque un metodo di acquisizione delle modifiche, una pausa finale delle scritture o una finestra di manutenzione per colmare il divario.

Usa una query di riconciliazione il cui risultato possa essere salvato nel registro del passaggio. Questo frammento verifica conteggi, limiti degli identificatori e finestre di aggiornamento per tre tabelle importanti:

SELECT 'users' AS table_name, count(*) AS rows,
       min(id)::text AS min_id, max(id)::text AS max_id,
       max(updated_at) AS newest_update
FROM users
UNION ALL
SELECT 'projects', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM projects
UNION ALL
SELECT 'orders', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM orders;

Eseguila su entrambi i lati e indaga ogni differenza. Poi prova invarianti di dominio che i conteggi non rilevano: nessun ordine punta a un utente assente, i saldi corrispondono al mastro, ogni record file ha un oggetto e le regole di unicità rifiutano gli stessi duplicati.

I backup richiedono un test di ripristino. Un file di esportazione riuscito prova soltanto che un comando è terminato. Ripristinalo in una destinazione vuota, esegui l'applicazione su di esso e misura il tempo. Quel tempo di ripristino indica se il rollback tramite ripristino è realistico o solo rassicurante.

Lo storage dei file spesso si nasconde dietro righe del database. Una tabella uploads esportata può conservare i nomi degli oggetti mentre gli oggetti reali restano in un bucket gestito dalla piattaforma. Copia byte, checksum, tipi di contenuto, regole di accesso e metadati di proprietà, poi prova scaricamenti campione attraverso l'applicazione anziché dalla console di storage. Se gli URL contengono token firmati o il vecchio nome host, rigenerali invece di copiare URL obsoleti. Tratta i caricamenti degli utenti come stato nella stessa finestra di passaggio, soprattutto quando gli utenti possono sostituire un file mentre gira la copia del database.

Le variabili d'ambiente rivelano architettura nascosta

Le variabili d'ambiente devono passare da un insieme ereditato di stringhe a un contratto nominato per ogni ambiente. Le variabili mancanti causano errori evidenti. Più pericolose sono quelle con valori di produzione plausibili ma sbagliati, come una chiave di pagamento di test, un vecchio segreto webhook o un'origine di callback che rimanda gli utenti al precedente host.

Censisci le variabili nel codice, nelle impostazioni della piattaforma, nella configurazione di build, nelle funzioni serverless, nei lavori pianificati e nel sistema di distribuzione. Non copiare tutto il vecchio ambiente nel nuovo host. Classifica ogni valore per proprietario, sensibilità, ambito, metodo di rotazione e momento di lettura, durante build o runtime.

Un manifesto compatto rende il confine verificabile:

DATABASE_URL          runtime   secret   owner=backend   rotate=yes
PUBLIC_APP_ORIGIN     build     public   owner=web       rotate=no
SESSION_SIGNING_KEY   runtime   secret   owner=security  rotate=yes
MAIL_SENDER           runtime   public   owner=ops       rotate=no
WEBHOOK_SECRET        runtime   secret   owner=backend   rotate=yes

La distinzione tra build e runtime conta nei front end in stile React. Un valore incorporato durante la build non cambia quando qualcuno modifica un'impostazione runtime. Ricompila il client e controlla il bundle distribuito per la configurazione pubblica. Non inserire mai un segreto in una variabile solo perché il suo nome inizia con il prefisso pubblico di un framework.

Ruota i segreti durante una migrazione dopo la crescita quando la destinazione può supportare un periodo di sovrapposizione. Per verifica dei webhook o firma delle sessioni, accetta per poco tempo il segreto vecchio e quello nuovo emettendo soltanto il nuovo. Rimuovi il valore precedente dopo la finestra massima di consegna o sessione. Se un provider supporta un solo segreto, coordina il cambio con il passaggio finale e rendi esplicita la dipendenza nel runbook.

Prima del lancio, elimina le variabili inutilizzate e fai fallire l'avvio se mancano valori obbligatori. Dopo la crescita, aggiungi osservabilità prima della pulizia per vedere se un'integrazione apparentemente obsoleta riceve ancora chiamate. Indovinare dai nomi delle variabili è il modo in cui i team disattivano il silenzioso lavoro mensile di cui la finanza ha davvero bisogno.

Confronta i valori per ambiente, ma non incollare mai segreti nel documento di migrazione. Registra nomi dei segreti ed etichette di versione, quindi conserva i valori nel secret store della destinazione. Concedi all'identità dell'app il permesso di leggere solo ciò che serve a quella distribuzione. Quando una variabile cambia, annota chi l'ha cambiata e quale release l'ha usata. Questa piccola disciplina risponde alla classica domanda della notte del passaggio: «Quale URL del database abbiamo davvero distribuito?»

Il passaggio del dominio è un cambiamento nel controllo del traffico

Un passaggio di dominio va progettato perché sia la vecchia sia la nuova distribuzione possano ricevere traffico in sicurezza durante la propagazione DNS. Il DNS non cambia ovunque nello stesso momento e ridurre il tempo di vita poco prima del cambiamento non influenza i resolver che hanno già memorizzato il valore precedente.

Diversi giorni prima dello spostamento pianificato, riduci il TTL del record pertinente e conferma la risposta autorevole. Mantieni sana la vecchia distribuzione almeno per il TTL precedente più un margine prudente per i resolver. Prepara il certificato sul nuovo host prima di dirigervi il traffico e verifica separatamente dominio apex, host www, sottodominio API, reindirizzamenti e record IPv6.

Il dominio è solo la porta d'ingresso. Aggiorna callback di autenticazione, origini consentite, domini dei cookie, URL canonici, endpoint webhook, link email e ogni configurazione di deep link mobile. Cerca il vecchio hostname nel repository e nelle impostazioni della piattaforma. Un reindirizzamento aiuta i browser, ma non corregge un callback OAuth rigoroso non corrispondente o un webhook firmato per l'endpoint sbagliato.

L'assenza di interruzioni è possibile solo se entrambe le versioni operano su stato compatibile. Se la nuova release modifica il database in modo che il vecchio codice non possa leggerlo, la sovrapposizione DNS crea errori. Usa modifiche allo schema di tipo espansione e contrazione: aggiungi prima la nuova colonna o tabella, distribuisci codice che comprende entrambe le forme, sposta i dati, poi rimuovi la vecchia forma quando tutto il traffico ha lasciato la vecchia release.

Per prodotti a basso volume, una breve finestra di manutenzione può essere più sicura di una complessa configurazione di replica in tempo reale. Dichiara quando le scritture si fermeranno, restituisci una corretta risposta di manutenzione, svuota il lavoro in background, effettua la copia finale, riconcilia i dati, cambia il traffico e riapri le scritture. L'accesso in sola lettura può restare disponibile se non può accodare lavoro nascosto.

Il rollback deve avere una regola sui dati. Riportare indietro il DNS è semplice quando nessuna scrittura ha raggiunto la destinazione. Quando gli utenti hanno scritto su entrambi i lati, un'inversione DNS può scartare o biforcare dati. Definisci l'ultimo momento sicuro per il rollback e, dopo quel momento, procedi in avanti o riconcilia le modifiche invece di fingere che invertire il traffico ripristini la coerenza.

Osserva l'applicazione dall'esterno del nuovo account di hosting. Risolvi il dominio tramite più resolver pubblici, richiedi la catena di certificati, carica una pagina senza cache calda, invia una transazione reversibile e conferma che il lavoro in background risultante termini. I dashboard dell'host possono segnalare una distribuzione sana mentre gli utenti ricevono una risposta DNS vecchia o un edge regionale serve una build precedente. Mantieni un controllo sintetico sia sul dominio pubblico sia su un host di test specifico della destinazione fino alla fine della sovrapposizione.

La pulizia del codice determina se lo spostamento dura

La pulizia del codice deve rimuovere il legame con la piattaforma senza cancellare una struttura generata utile né innescare una riscrittura estranea. Il codice generato può essere ripetitivo o scomodo, ma il fastidio estetico non è un requisito di migrazione. Cambia ciò che impedisce build indipendenti, test, revisione della sicurezza o manutenzione futura.

Inizia dalla provenienza. Esporta il repository completo e conserva file di licenza, attribuzioni delle risorse, migrazioni generate, lockfile e configurazione. Controlla se segreti o token della piattaforma sono entrati nella cronologia Git. Rimuoverli dall'ultimo file non li revoca, quindi ruota le credenziali esposte e decidi se riscrivere la cronologia sia giustificato.

Poi trova import specifici della piattaforma, percorsi proxy, client database, helper di autenticazione, adattatori di storage, file di distribuzione ed endpoint API generati. Dove è pratico, sostituiscili dietro interfacce applicative ristrette. Una ricerca nell'intero repository è utile, ma eseguire i percorsi utente mostra quali riferimenti contano ancora.

La pulizia delle dipendenze viene dopo che la build indipendente funziona. Rimuovi pacchetti uno alla volta, rigenera il lockfile con il gestore pacchetti esistente ed esegui i test dopo ogni gruppo. Non aggiornare il framework, sostituire la gestione dello stato, rinominare tutti i componenti e migrare l'hosting nella stessa modifica. Creeresti troppe spiegazioni possibili per un solo errore.

Il codice server generato merita un controllo aggiuntivo ai confini di fiducia. Segui ogni richiesta dalla route al controllo di autorizzazione fino alla query del database e verifica che il server non dipenda da una regola di visibilità lato client. Esamina limiti di caricamento, destinazioni delle richieste in uscita, messaggi di errore e route amministrative. Non è un invito a riscrivere ogni handler generato. È una verifica mirata che il codice continui a imporre le regole di accesso dopo la scomparsa di middleware della piattaforma e proxy gestiti.

Il progetto generato richiede anche normali file operativi: un manifesto d'ambiente di esempio con valori fittizi, comandi per migrare il database, istruzioni di build e avvio, health check e una descrizione dei worker in background. Mantieni queste istruzioni eseguibili. Un README che dice «configura il database» registra solo che un database esiste.

Prima del lancio, la pulizia può includere reset dello schema e grandi refactoring perché non esiste una promessa di compatibilità. Dopo la crescita, conserva forme delle API pubbliche, identificatori e comportamento visibile agli utenti finché lo spostamento dell'infrastruttura non si stabilizza. Concedi alla nuova distribuzione un periodo tranquillo prima di cambiare il comportamento del prodotto. Quando migrazione e redesign arrivano insieme, l'assistenza non può capire se un reclamo nasce dallo spostamento o dalla nuova funzione.

La prova trasforma l'interruzione in una decisione

Una prova di migrazione deve riprodurre la sequenza di produzione con una copia recente e anonimizzata dei dati, producendo tempi misurati, risultati di riconciliazione e un punto di interruzione testato. Una checklist copiata da un altro progetto non può dirti quanto tempo impiega il tuo database a ripristinarsi o quale lavoro continua a scrivere dopo l'avvio della manutenzione.

Usa un operatore per eseguire e un altro per osservare, registrare i tempi e contestare i controlli saltati. In un team piccolo, la seconda persona può essere il fondatore, ma deve avere abbastanza contesto per riconoscere un risultato cambiato. Chi digita i comandi non dovrebbe essere anche l'unica persona a decidere se hanno funzionato.

Un runbook pratico segue un ordine rigoroso:

1. Blocca le distribuzioni non correlate e registra versioni correnti, valori DNS e versioni dei segreti.
2. Metti le scritture in manutenzione, svuota le code, ferma i lavori pianificati e registra l'ultimo watermark dell'origine.
3. Copia i dati rimanenti, riconcilia tabelle e invarianti di dominio, poi esegui test di autenticazione e dei percorsi principali.
4. Cambia il traffico, verifica certificati e callback, osserva errori e profondità delle code, poi riapri le scritture.
5. Al checkpoint dichiarato, continua sul nuovo sistema oppure applica la regola di rollback dei dati documentata.

Prima del lancio, prova distruggendo la destinazione e ricostruendola dal repository. L'obiettivo è la riproducibilità, quindi un database vuoto e un ambiente nuovo rivelano più di una copia simile alla produzione.

Dopo la crescita, prova scala e concorrenza. Copia abbastanza dati rappresentativi da rivelare indici lenti e migrazioni lunghe. Riproduci traffico di lettura sicuro se lo possiedi, crea scritture sintetiche con identificatori noti e verifica che i lavori in background siano idempotenti prima di consentire ritenti. Un lavoro email che invia due volte non è innocuo solo perché il database è rimasto coerente.

Misura la pausa delle scritture separatamente dall'intera finestra di manutenzione. Spesso puoi effettuare la copia di massa mentre l'origine resta attiva e sospendere soltanto per il delta e la convalida. Se la prova mostra che il delta non può terminare nella finestra consentita, aggiungi replica o acquisizione delle modifiche. Non scoprire questo requisito mentre i clienti aspettano.

Conserva le prove dopo il passaggio: versioni di origine e destinazione, timestamp, controlli delle righe, risultati degli smoke test, risposte DNS, decisioni degli operatori e orario di disattivazione dei vecchi servizi. Questo registro accelera il debug e impedisce che il prossimo piano di migrazione dipenda dalla memoria di qualcuno.

Scegli la fase in base alla reversibilità

La fase migliore per migrare è quella in cui il guasto che puoi realisticamente causare resta reversibile. Prima del lancio, il prodotto ha pochi riscontri ma libertà quasi illimitata. Dopo la crescita, ha riscontri ma trasporta stato che deve restare coerente durante tutto lo spostamento.

Uso sei test decisionali:

• Migra prima del lancio se un vincolo noto di conformità, proprietà, esportazione, hosting o architettura blocca la release prevista.
• Resta e lancia se la piattaforma soddisfa le esigenze attuali e il team migrerebbe altrimenti solo per ansia.
• Migra dopo la crescita se l'uso misurato espone un vincolo e puoi provare la continuità di identità, dati e traffico.
• Rimanda se non puoi esportare un database ripristinabile, controllare il dominio, elencare i segreti o definire la proprietà delle scritture.
• Preferisci una separazione incrementale quando autenticazione o dati possono restare temporaneamente mentre si spostano calcolo e hosting.

Lovable, Bolt, v0 e Replit possono tutti produrre progetti la cui portabilità dipende dai servizi scelti, dal piano in uso e dal codice generato in quel momento. Esamina il repository reale e i controlli dell'account. Una categoria di fornitori non dice se i tuoi hash delle password, estensioni del database, file o impostazioni di distribuzione specifici possono essere spostati.

Se scegli un nuovo ambiente di sviluppo basato sulla chat, controlli di pianificazione e rollback riducono il costo di separare lo spostamento in modifiche verificabili. Koder.ai supporta l'esportazione dei sorgenti, la distribuzione e l'hosting, i domini personalizzati, gli snapshot e il rollback, così un team può mantenere questi controlli di proprietà nel piano di migrazione senza far dipendere i consigli dell'articolo da una sola piattaforma.

Definisci un budget di migrazione prima del lancio anche se decidi di restare. Mantieni il codice sotto il tuo controllo, versiona lo schema, documenta il contratto dell'ambiente e prova un ripristino. Queste azioni costano molto meno quando l'app è piccola e conservano l'opzione di spostarsi quando la crescita offre una ragione invece di una crisi.

Se il team non riesce a eseguire quel ripristino oggi, la portabilità resta un'intenzione e non una proprietà dell'applicazione.