Tota la plataforma que has vist en aquest curs és nova. Es va dissenyar a Azure, es va construir a Azure i no arrossega res. Però Contoso Airlines no va començar a existir amb aquest projecte: fa vint anys que funciona, i al centre de dades de Barcelona continuen encesos els sistemes que sostenen bona part del negoci. El contracte d'allotjament venç d'aquí a divuit mesos i la direcció ha demanat una decisió: renovar o migrar.

Aquesta decisió no és tècnica. Moure un servidor és fàcil; el difícil és que després de moure'l l'organització en sàpiga operar, que algú sigui propietari del seu cost, que l'equip que l'administrava a mà accepti que ara es desplega per canalització, i que la migració es planifiqui en onades en lloc d'en un cap de setmana heroic. La major part dels projectes de migració que fracassen no fracassen per un problema de xarxa: fracassen per manca de cas de negoci, per inventaris incomplets o per resistència interna que ningú no va gestionar.

El Cloud Adoption Framework de Microsoft existeix exactament per a això: és la guia que cobreix el cicle complet —estratègia, pla, preparació, adopció, governança i administració— i que tracta el núvol com un canvi organitzatiu amb part tècnica, i no a l'inrevés. Aquesta lliçó el recorre sencer aplicant-lo al que queda a Barcelona: el cas de negoci amb el TCO ja calculat, l'inventari amb Azure Migrate, les sis estratègies de migració amb l'assignació de cada sistema, les zones d'aterratge, les onades amb el seu calendari i la seva finestra de tall, la migració de les dades, la tornada enrere, la gestió del canvi i la retirada del centre de dades amb els seus costos ocults.

Recordatori: totes les xifres són orientatives i fictícies. El TCO real d'un centre de dades depèn de contractes, amortitzacions i personal que només coneix cada organització.

1. Què queda a Barcelona
2. El Cloud Adoption Framework i les seves fases
3. Motivacions i cas de negoci
4. Inventari i avaluació amb Azure Migrate
5. Les sis estratègies de migració
6. Zones d'aterratge d'Azure
7. Onades de migració i calendari
8. Migració de dades
9. La finestra de tall i la tornada enrere
10. Gestió del canvi
11. Retirada del centre de dades
12. Què s'innova després
13. Errors Comuns i Consells
14. Exercicis
15. Conclusió

Ja existeix una VPN lloc a lloc amb vgw-contoso-pro, de manera que la connectivitat no és el problema. El problema és que aquests sis elements tenen dependències entre si que ningú no ha dibuixat mai, i que cadascun té un propietari diferent dins de l'organització.

Dues observacions sobre el marc. Primer, governança i administració són transversals, no fases finals: si es deixen per al final, la migració crea en tres mesos el desordre que es trigarà dos anys a netejar. Segon, adoptar no és només migrar: Contoso ja va innovar —va construir la plataforma nova— abans de migrar el que és vell, i aquest ordre és més comú del que suggereixen els diagrames.

Les motivacions determinen l'ordre i el criteri d'èxit de tota la migració, així que convé ordenar-les explícitament:

El cas de negoci compara el TCO actual amb el cost previst a Azure més el cost del mateix projecte. La dada de partida ja la tens: el TCO real del centre de dades de Barcelona és de 340.000 €/any, xifra que inclou el que gairebé ningú no compta al principi.

Amb aquests números el retorn arriba al voltant del segon any, i aquest és exactament el missatge que cal donar a direcció: no és un estalvi immediat. Prometre estalvi el primer mes és la manera més ràpida de perdre la credibilitat del projecte, perquè durant la migració es paguen les dues coses alhora: el centre de dades que encara no s'ha apagat i Azure que ja està encès.

Azure Migrate és el centre des del qual es descobreix, s'avalua i es mou. El seu valor no és al motor de replicació —això és el fàcil—, sinó al descobriment de dependències, que és el que revela les sorpreses.

El resultat del descobriment a Contoso, amb la sorpresa clàssica:

Els cinc servidors sense propietari il·lustren per què el descobriment es fa abans de planificar: dos d'ells rebien trànsit, així que apagar-los «perquè ningú no els reclama» hauria trencat alguna cosa. La regla és apagar-los primer de manera controlada —desconnexió temporal amb vigilància—, i només retirar-los si ningú no protesta.

L'assignació de Contoso, que és on es veu el criteri:

Fixa't en la fila més important: no tot es migra. Un pla de migració honest té una columna de «es queda» i una de «es retira», i totes dues milloren el resultat.

Una zona d'aterratge és l'entorn preparat abans que arribi la primera càrrega: identitat, xarxa, governança, seguretat, observabilitat i organització de subscripcions ja resoltes, de manera que cada aplicació que aterra hereti tot això en lloc d'improvisar-ho.

El que resol, i que altrament es resol malament trenta vegades:

Contoso ja té una zona d'aterratge incipient i aquesta és la bona notícia del projecte: mg-contoso amb mg-contoso-plataforma i mg-contoso-cargas, la iniciativa «Base de gobernanza de Contoso», el concentrador amb tallafoc i VPN, l'àrea de registres única i els grups d'Entra ID són exactament els components de plataforma d'una zona d'aterratge. El que falta per a les càrregues de Barcelona és una subscripció nova per a les càrregues migrades, ampliar el pla d'adreçament i afegir la resolució de noms híbrida.

Opcions d'implementació, de menys a més formalitat: començar amb una zona inicial i madurar després; desplegar l'accelerador de zona d'aterratge empresarial, que crea la jerarquia completa amb les seves directives; o construir-la a mida amb Bicep, que és el natural quan ja existeixen plantilles pròpies com contoso-infra. Contoso tria la tercera: estendre el que ja té.

Migrar-ho tot alhora és la manera més segura de fracassar. S'agrupen les càrregues en onades, cadascuna amb la seva finestra, els seus criteris d'èxit i el seu pla de tornada enrere.

Criteris per agrupar: per dependència —el que es parla entre si va junt—, per risc creixent —el que és fàcil primer, per aprendre—, per calendari de negoci —mai en tancament fiscal ni en temporada alta— i per capacitat de l'equip, que és el límit real.

El pilot de l'onada 1 no es tria per importància sinó per capacitat d'ensenyar: el servidor de fitxers toca xarxa, identitat, permisos i usuaris reals, amb un impacte baix si alguna cosa surt malament. Un pilot que no ensenya res és un pilot malbaratat; un que pot tombar el negoci no és un pilot.

I la facturació va l'última deliberadament, tot i ser la que més urgeix per llicències: és la de més risc, i quan arribi l'equip haurà executat quatre migracions. A més, la seva finestra evita el tancament trimestral.

Les dades són la part que no admet improvisació, perquè és l'única que no es pot repetir sense conseqüències.

Regla de decisió sobre el volum: calcula el temps de transferència real amb l'amplada de banda disponible descomptant el trànsit productiu. Dotze terabytes per un enllaç de 200 Mbps compartit no són «unes hores»; amb sort són diversos dies de transferència contínua, i per això existeix Data Box.

Per a bases de dades, el patró que minimitza el risc és sempre el mateix: càrrega inicial, replicació contínua, validació en paral·lel, tall curt. La validació en paral·lel —comparar recomptes, sumes de control i alguns informes de negoci entre origen i destí abans de tallar— és el que converteix el tall en un tràmit.

Els dos elements que fan que això funcioni són el punt de decisió amb hora fixa i l'origen intacte. Sense hora fixa, un tall problemàtic s'allarga «una mica més» fins que ja no hi ha temps de tornar; i la tornada enrere només és possible si el sistema original no s'ha tocat i se sap quines dades s'han escrit al destí des del tall. Per això els criteris d'èxit i de tornada enrere s'escriuen abans, quan ningú no està cansat ni sota pressió.

Aquí és on fracassen les migracions que tècnicament anaven bé. Després de migrar, la feina de les persones canvia:

Nous papers que apareixen, i que convé anomenar explícitament perquè algú els ocupi: equip de plataforma —propietari de la zona d'aterratge, les plantilles i les baranes—, FinOps —la Nuria, amb dedicació real i no com a tasca residual—, i SRE o operació de servei —propietari d'alertes, guàrdies i fiabilitat—.

La resistència interna és un risc de projecte tan real com una incompatibilitat tècnica, i gairebé sempre està justificada: qui porta quinze anys administrant servidors sent «migrem al núvol» com «la teva feina desapareix». El que funciona, per ordre: formar abans de migrar, no després; donar a aquestes persones la propietat del nou entorn en lloc de portar algú de fora a fer-ho; fer explícit que el coneixement de les aplicacions i del negoci és insubstituïble; i comunicar amb honestedat què canvia. El que no funciona: prometre que no canviarà res.

Migrar no acaba quan arrenca l'última màquina a Azure: acaba quan el contracte es rescindeix, i aquí és on apareixen els costos que ningú no va pressupostar.

L'últim és el que més vegades sorprèn: s'apaga el centre de dades i mesos després algú demana una còpia de fa cinc anys, i ja no queda cap lector de cintes. Abans de retirar res, cal decidir si l'arxiu històric es migra o es conserva llegible, i aquesta decisió afecta l'equip legal.

Migrar no és la meta: és deixar de pagar per mantenir el que no diferencia el negoci per poder gastar en el que sí. Amb Barcelona apagat, el que s'obre per a Contoso:

• Facturació modernitzada: un cop estabilitzada a Managed Instance, refactoritzar-la cap a App Service i alliberar el sistema operatiu.
• Analítica sobre dades que abans estaven preses: les dades de manteniment i de facturació poden entrar a stlagocontosopro i creuar-se amb reserves.
• Automatització de processos que avui depenen d'intervenció al centre de dades.
• Elasticitat real en temporada, que era una de les motivacions originals i fins ara només aplicava a la plataforma nova.
• Un segon emplaçament sense comprar ferro: la continuïtat que mai no va existir.

I un advertiment final sobre l'ordre: la temptació de rearquitecturar durant la migració és forta i gairebé sempre és un error. Mou primer, estabilitza, i modernitza després amb el sistema ja a Azure i amb mètriques reals. Qui intenta les dues coses alhora sol acabar sense cap.

• Començar per la càrrega més crítica. L'aprenentatge es fa al pilot, no a la facturació.
• Migrar sense inventari de dependències. És el que provoca el «funcionava i ara no» del dilluns següent.
• Reallotjar-ho tot i anomenar-ho transformació. Es paga el núvol sense cap dels seus avantatges; si es reallotja, amb data de modernització.
• Prometre estalvi immediat. Durant la migració es paga dues vegades; direcció ho ha de saber des del primer dia.
• Deixar la governança per després. La zona d'aterratge va abans que la primera càrrega, sempre.
• No definir criteris de tornada enrere. Sense ells, la decisió es pren cansat, de matinada i malament.
• Oblidar la formació de l'equip. Sense ella, la plataforma nova s'opera amb hàbits vells.
• Descuidar el preavís del contracte. Es pot acabar la migració i continuar pagant un any.
• Consell: retira el que és inútil abans de migrar. És la feina amb millor relació esforç-benefici del projecte.
• Consell: mesura i publica l'avenç en càrregues migrades i en cost del centre de dades restant. Un projecte de 18 mesos necessita victòries visibles.
• Consell: reserva pressupost per al solapament des del principi; és el sobrecost més previsible i el que pitjor cau quan apareix per sorpresa.

Exercici 1. Assigna una estratègia de migració —reallotjar, refactoritzar, rearquitecturar, reconstruir, reemplaçar o retirar— a cadascun d'aquests cinc sistemes d'una empresa logística, justificant cada elecció i assenyalant quina informació et falta per decidir amb seguretat: (a) un ERP comercial amb suport oficial a Azure; (b) una aplicació web pròpia en .NET Framework amb SQL Server; (c) un servidor de correu Exchange local; (d) una aplicació d'escriptori que fan servir 8 persones i que el seu autor va abandonar; (e) un servidor d'informes que ningú no ha obert en sis mesos.

Exercici 2. Dissenya les onades de migració d'aquesta mateixa empresa —12 servidors, 4 TB de dades, tancament comptable el dia 5 de cada mes, temporada alta al novembre i al desembre, equip de 3 persones de sistemes— amb un termini de 12 mesos. Defineix el pilot i per què, l'ordre de les onades, les finestres que cal evitar i els criteris d'èxit de cadascuna.

Exercici 3. La direcció d'una empresa mitjana pregunta: «migrar al núvol ens estalviarà diners?». Prepara la resposta completa: quins elements inclou un TCO honest a banda i banda, per què l'estalvi no apareix el primer any, quins beneficis no són estalvi però sí valor, en quins casos la resposta correcta és no migrar, i quins compromisos demanaries a direcció abans d'acceptar el projecte.

Solució 1: (a) ERP comercial amb suport a Azure: reallotjar, o refactoritzar si el fabricant ofereix una versió gestionada; mai tocar-ne l'arquitectura, perquè es perd el suport. Falta saber si el contracte de llicència permet execució en núvol públic i si existeix una oferta SaaS del mateix fabricant, cas en què reemplaçar podria ser millor. (b) Aplicació .NET Framework amb SQL Server: refactoritzar és el raonable —la base de dades a Azure SQL Managed Instance, que admet característiques que la base de dades aïllada no, i l'aplicació a màquines virtuals o App Service amb Hybrid Benefit—; rearquitecturar només si a més cal elasticitat i hi ha pressupost per a proves. Falta saber si fa servir components locals del servidor, cues MSMQ, tasques programades o rutes de disc codificades, que és el que sol trencar el trasllat. (c) Exchange local: reemplaçar per Exchange Online; migrar servidors de correu a màquines virtuals és pagar per continuar administrant el que ja existeix com a servei. Falta conèixer el volum de bústies, els requisits de retenció i si hi ha integracions amb aplicacions internes. (d) Aplicació d'escriptori abandonada i feta servir per 8 persones: la resposta depèn del negoci, no de la tecnologia —si el procés és prescindible, retirar; si és imprescindible, reemplaçar per una alternativa comercial, i només com a últim recurs reallotjar en un escriptori virtual per guanyar temps—. Falta saber quin procés suporta i si existeix alternativa al mercat. (e) Servidor d'informes sense ús en sis mesos: candidat clar a retirar, però amb el procediment correcte: apagada controlada amb vigilància durant un mes abans d'eliminar, perquè un informe trimestral o anual no apareix en una finestra de sis mesos. Falta comprovar accessos reals i preguntar a finances.

Solució 2: onada 0, preparació (mesos 1-2): zona d'aterratge, xarxa i VPN, identitat híbrida, formació de l'equip de tres persones —que és el coll d'ampolla real i per això la formació és part del pla, no un extra—, i inventari amb anàlisi de dependències. Pilot (mes 3): un sistema de baix impacte però representatiu, per exemple el servidor de fitxers o un entorn de proves complet; ensenya xarxa, permisos, transferència de dades i experiència d'usuari sense posar en risc l'operació, i permet mesurar quant triga de debò l'equip. Onada 1 (mesos 4-5): servidors d'infraestructura —identitat i serveis comuns—, perquè tota la resta en depèn. Onada 2 (mesos 6-7): aplicacions de suport no crítiques, agrupades per dependència. Onada 3 (mesos 8-9): dades i aplicacions de negoci de risc mitjà; els 4 TB es planifiquen aquí, avaluant xarxa davant de Data Box segons l'amplada de banda real. Onada 4 (mes 10): el sistema comptable, evitant sempre els dies 1 a 8 de cada mes pel tancament. Onada 5 (mesos 11-12 amb la salvetat següent): retirada i tancament. Finestres prohibides: novembre i desembre sencers per temporada alta —cosa que a la pràctica comprimeix el calendari i obliga a acabar el que és crític a l'octubre o desplaçar-ho al gener—, i els primers dies de cada mes. Criteris d'èxit per onada: aplicacions accessibles i amb rendiment igual o millor mesurat, zero pèrdues de dades verificades per recompte i sumes de control, incidències per sota d'un llindar acordat durant dues setmanes, origen encara disponible durant 30 dies i cost real dins de l'estimació. Un apunt de realisme: tres persones no poden migrar i operar alhora, així que o es reforça l'equip temporalment o el termini de 12 mesos és optimista.

Solució 3: un TCO honest del costat local inclou allotjament, energia i climatització, amortització del maquinari i la seva renovació prevista, llicències de virtualització i sistemes, personal dedicat a mantenir infraestructura —el més oblidat—, suport i contractes, connectivitat, còpies i la seva custòdia, assegurances i, si es vol ser rigorós, el cost d'oportunitat del capital immobilitzat i el risc de no tenir segon emplaçament. Del costat d'Azure: consum de còmput, emmagatzematge i xarxa, sortida de dades, llicències traslladades o noves, eines de migració, formació, hores de projecte, consultoria, el solapament durant la transició i el cost operatiu continu del nou model. Per què no hi ha estalvi el primer any: perquè es paguen les dues infraestructures alhora, perquè el projecte té un cost únic important i perquè les càrregues acabades de migrar estan sense optimitzar —l'estalvi real arriba amb el dimensionament, les reserves i la modernització posteriors—. Beneficis que no són estalvi però sí valor: elasticitat per a pics que abans es perdien en vendes, temps d'aprovisionament de setmanes a minuts, continuïtat de negoci sense comprar un segon centre de dades, capacitat d'experimentar amb cost marginal, serveis que no es poden construir a casa —IA, analítica—, seguretat i compliment amb eines de nivell empresarial, i alliberar l'equip de tasques que no diferencien el negoci. Quan la resposta correcta és no migrar: quan el maquinari està acabat de comprar i sense amortitzar, quan existeix una restricció legal de residència o sobirania que no es pot satisfer, quan la càrrega és constant i previsible durant anys i surt més barata en local, quan hi ha una dependència física insalvable, quan l'organització no té ni pot adquirir les competències, o quan l'aplicació crítica és un binari sense suport que ningú no sap reconstruir. Compromisos que demanaria a direcció: un patrocinador executiu amb capacitat de decidir, pressupost explícit per al solapament i la formació, acceptació per escrit que el retorn arriba el segon any, dedicació real de les persones del projecte —no a estones entre incidències— i autoritat per retirar sistemes i dir que no a migracions que no tenen sentit.

Ja saps que migrar no és moure màquines: és un canvi organitzatiu amb una part tècnica. Coneixes el Cloud Adoption Framework i les seves fases —estratègia, pla, preparació, adopció amb migració i innovació, governança i administració—, amb les dues observacions que més s'obliden: que governança i administració són transversals i no fases finals, i que adoptar inclou innovar, no només mudar el que és vell.

Saps construir el cas de negoci partint de les motivacions ordenades —el contracte que venç, la renovació de maquinari, els pics de temporada, l'agilitat, el suport que es retira, la continuïtat inexistent— i d'un TCO complet: els 340.000 €/any de Barcelona davant dels ≈205.000 € en estat estable més ≈120.000 € de projecte, amb el missatge honest que el retorn arriba el segon any perquè durant la migració es paga dues vegades. Saps fer l'inventari amb Azure Migrate —descobriment, avaluació, dependències i migració— i per què les dependències són el que revela les sorpreses: 34 servidors on n'hi havia 26 de documentats, cinc sense propietari i dos d'ells amb trànsit.

Manegues les sis estratègies amb el seu esforç, risc i benefici, i l'assignació raonada de cada sistema de Contoso, incloses les dues columnes que milloren qualsevol pla: el que es retira i el que es queda. Entens què és una zona d'aterratge, què resol, la seva arquitectura conceptual i el fet que la jerarquia mg-contoso amb la seva iniciativa de governança, el concentrador i l'àrea de registres única ja són una zona d'aterratge incipient. Saps organitzar onades amb el seu pilot triat per capacitat d'ensenyar, el seu calendari de 18 mesos que respecta tancaments i temporada alta, i els seus criteris d'èxit; triar la via de migració de dades —Database Migration Service, còpia i restauració, Data Box per als 12 TB, sincronització de fitxers o replicació— amb el patró de càrrega inicial, replicació, validació en paral·lel i tall curt; i executar la finestra de tall amb el seu punt de decisió a hora fixa i la seva tornada enrere preparada per escrit.

I saps el que gairebé mai no és als plans: la gestió del canvi —qui opera què després, els papers de plataforma, FinOps i SRE, i la resistència interna com a risc real que es gestiona formant abans de migrar i donant la propietat del nou entorn a qui administrava el vell—, la retirada del centre de dades amb els seus costos ocults —solapament, preavís, esborrat certificat, llicències amb permanència, restauració del local i les cintes que sobreviuen al lector— i què s'innova després, amb la regla d'or: moure primer, estabilitzar, modernitzar després.

Amb això, Contoso Airlines té la seva plataforma nova construïda i el camí traçat per al que queda a Barcelona. Queda una última lliçó, que mira endavant en lloc de cap enrere: cap on va Azure —IA integrada a tot, enginyeria de plataforma, sense servidor per defecte, núvol distribuït, sostenibilitat, confiança zero i regulació europea—, com mantenir-se al dia sense ofegar-se, i el mapa complet de certificacions amb la que correspon al teu perfil i què et falta per presentar-t'hi després d'aquest curs.