Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Scegliere uno strumento di migrazione per il rehosting dei database
Mike Kuznetsov e Harpreet Virk, Amazon Web Services (AWS)
Giugno 2022 (cronologia dei documenti)
Quando prevedi di migrare i tuoi carichi di lavoro di grandi dimensioni verso AWS, ti consigliamo di seguire le linee guida AWS e di suddividere il processo di migrazione in tre fasi: valutazione, mobilitazione e migrazione. Il percorso di migrazione coinvolge molti fattori, tra cui ambito ("cosa?"), strategia ("perché?") e cronologia ("quando?"), come discusso nella sezione Strategia e best practice per migrazioni AWS di grandi dimensioni. Ogni carico di lavoro che scegli di migrare potrebbe seguire una strategia di migrazione diversa, come definita in sette strategie comuni (7 R). La maggior parte dei carichi di lavoro segue lo scenario di rehosting per le migrazioni. lift-and-shift Dopo aver selezionato una strategia, puoi rispondere alla domanda "come?", che si concentra su almeno tre aspetti (persone, tecnologia e processi).
Questa guida è destinata a chiunque intenda migrare i propri carichi di lavoro on-premise verso Cloud AWS, inclusi dirigenti IT e aziendali, responsabili di programmi e progetti, proprietari di prodotti e gestori delle operazioni e dell'infrastruttura.
Questa guida si concentra sul percorso di migrazione di rehosting, che prevede lo spostamento di un'applicazione sul cloud senza apportare modifiche per sfruttare le funzionalità del cloud. Ad esempio, la migrazione del database Microsoft SQL Server on-premise a SQL Server su un'istanza di Amazon Elastic Compute Cloud (Amazon EC2) nel Cloud AWS è una strategia di rehosting. Più specificamente, la guida illustra gli strumenti più adatti per lift-and-shift le migrazioni di carichi di lavoro che includono i database e i fattori da considerare nella scelta di un particolare servizio per la migrazione. Risponde a domande come: quale servizio supporta meglio le migrazioni di database? Il servizio utilizzato per i server non di database può essere utilizzato anche per i server di database o i server di database devono essere trattati in modo diverso? E se la mia migrazione di rehosting si trasformasse in un approccio misto di rehosting e ridefinizione della piattaforma?
