Hoe een on-premises server naar AWS te migreren (eenvoudige runbook)

Introductie

On-prem naar AWS-migraties falen minder door rekenkracht en meer door planningsgaten: onduidelijke overstapdoelen, over het hoofd geziene afhankelijkheden en gehaaste tests. Deze gids houdt het proces eenvoudig te volgen terwijl het operationeel blijft. Je zult definiëren hoe succes eruitziet, een minimale landingszone voorbereiden, AWS MGN-testlanceringen uitvoeren, zelfverzekerd overstappen en vervolgens de werklast optimaliseren nadat deze live is.

Wat moet je beslissen voordat je iets migreert?

Welke migratiestrategie past bij deze server (de AWS "7 Rs")?

De snelste manier om tijd te verliezen is door het verkeerde te migreren. Voordat je een agent installeert, bepaal welke migratiestrategie de server verdient, zodat je niets tilt en verplaatst dat moet worden uitgefaseerd of vervangen. In de praktijk beginnen veel teams met rehosting voor snelheid, en optimaliseren ze later zodra de werklast stabiel is in AWS.

Echter, dat werkt alleen wanneer de server een goede "as-is" kandidaat is en onmiddellijk na de overstap geen dure technische schuld creëert. Praktische beslissingsverkortingen:

• Herverhuizen: beweeg snel met minimale veranderingen wanneer de tijd krap is.
• Herplatformeren: houd de app maar maak kleine aanpassingen voor AWS.
• Refactor: reserveer inspanning voor bedrijfskritische differentiators.
• Hernieuw aankoop: vervangen met SaaS in plaats van de server te migreren.
• Afsluiten/Behouden: verwijder ongebruikte systemen of houd beperkte werklasten on-prem.

Een nuttig intern controlepunt is om te vragen of de werklast een "cloudtoekomst" heeft. Als de server later zal worden ontleed in beheerde diensten of gecontaineriseerd, documenteer dat dan nu en beschouw rehosting als een tijdelijke stap in plaats van een permanent ontwerp.

Wat zijn de RTO/RPO, de downtime-vensters en de rollback-triggers?

Cutovers slagen wanneer succes meetbaar is. Definieer de acceptabele uitvaltijd en tolerantie voor dataverlies, en schrijf vervolgens de voorwaarden op die een terugrol afdwingen. Dit houdt het migratieobjectief en voorkomt dat teams improviseren tijdens het cutovervenster. Het helpt ook zakelijke belanghebbenden om goedkeuring te geven, omdat ze precies kunnen zien welk risico wordt geaccepteerd.

Definieer en documenteer:

• RTO: maximale aanvaardbare downtime.
• RPO: maximale aanvaardbare gegevensverlies.
• Downtime venster: wanneer je toestemming hebt om productieverkeer om te schakelen.
• Rollback triggers: specifieke foutvoorwaarden (auth-uitval, mislukte transacties, gegevensmismatch).
• Overgangsmechanisme: DNS flip, load balancer switch, routing/firewall wijzigingen.

Om het terugrolplan realistisch te houden, geef aan wie verantwoordelijk is voor elke actie tijdens de overstap. Bijvoorbeeld, één persoon is verantwoordelijk voor DNS-wijzigingen, één voor applicatievalidatie, en één voor de "terugrolbeslissing" op basis van de bovenstaande triggers.

Wat heb je nodig in AWS en on-premises als eerste?

Connectiviteit en firewallbasis voor replicatie

Replicatie werkt alleen als de bronomgeving consistent verbinding kan maken met AWS. De meest voorkomende blokkades zijn strikte uitgaande controles, proxies en TLS-inspectie die de uitgaande HTTPS-verkeer verstoren. Valideer de connectiviteit vroeg en houd het netwerkpad stabiel tijdens de initiële replicatie en testlanceringen. In veel omgevingen is replicatie niet "volledig geblokkeerd"; in plaats daarvan veroorzaken intermitterende onderbrekingen of pakketinspectie onstabiel gedrag dat later moeilijk te diagnosticeren is.

Veelvoorkomende verbindingspatronen:

• Publieke internetuitgang (simpelste wanneer toegestaan)
• Site-to-site VPN (gebruikelijk voor privéverbinding)
• Direct Connect (meer voorspelbaar voor grotere omgevingen)

Voorafgaande controles:

• Uitgaande HTTPS werkt betrouwbaar vanuit het bronnennetwerk
• Proxygedrag wordt begrepen en getest met de migratiestroom
• Beveiligingsteams keuren de vereiste uitgang goed voor het migratievenster

Als uw omgeving sterk beveiligd is, voeg dan een korte "netwerkbevestiging" stap toe aan uw golfplan: valideer eindpunten vanaf één pilotserver en replicateer vervolgens die exacte regelset voor de rest van de golf.

Minimale checklist voor AWS-landingzone

Je hebt geen perfecte landingszone nodig om te beginnen, maar je hebt wel een consistente doelstelling nodig die niet halverwege verandert. Houd de opbouw minimaal, maar doordacht, zodat de tests weerspiegelen hoe de overstap eruit zal zien. Veel migratieproblemen ontstaan door "tijdelijke" netwerksnelkoppelingen die permanent worden omdat niemand tijd heeft om ze na de lancering opnieuw op te bouwen.

Minimale elementen van de landingszone:

• A VPC en subnetten waar instanties zullen worden gestart (vaak aparte test vs productie)
• Beveiligingsgroepen uitgelijnd op echte applicatiestromen (vermijd "nu openen, later oplossen")
• IAM klaar voor migratieoperaties en toegang en tools op de tweede dag
• Basis tagging zodat eigendom en kostenbeheer duidelijk zijn na de overstap

Het helpt ook om vroeg te beslissen hoe beheerders toegang zullen krijgen tot instanties (bastion, VPN , SSM) en hoe de uitgaande internettoegang zal worden geleverd (NAT-gateway, proxy). Deze keuzes beïnvloeden het patchen, de monitoringagents en het oplossen van problemen op de eerste dag.

Checklist voor de gereedheid van de bronserver

Een schone migratie hangt af van een schone bron. Bevestig dat de werklast compatibel is met de gekozen methode, en identificeer vervolgens alles wat afhankelijk is van lokale aannames die zullen veranderen in AWS. Dit is ook waar je "speciale geval" servers markeert die mogelijk een andere volgorde vereisen. Bijvoorbeeld, een bestandserver met zware schrijfactiviteit heeft mogelijk een striktere overstapperiode en strengere validatie voor open bestanden en shares nodig.

Klaarheidscontroles die verrassingen voorkomen:

• OS/werklastcompatibiliteit met de migratieaanpak
• Voldoende schijfruimte en constante I/O voor replicatie-overhead
• Afhankelijkheden in kaart gebracht: DNS , AD/LDAP intern, intern PKI/certificaten , databases, shares
• Verborgen broosheid: hardgecodeerde IP's, verouderde TLS, ongebruikelijke geplande taken
• Speciale gevallen vroeg gemeld: domeincontrollers, clusters, apparaten, dongle-licenties

Voordat u deze stap verlaat, leg "moet hetzelfde blijven" items vast, zoals hostnaam, IP-adresvereisten of certificaatbindingen, omdat deze rechtstreeks invloed hebben op uw AWS-launchinstellingen en uw overstapvolgorde.

Hoe migreer je een server naar AWS met AWS MGN?

Initialiseer MGN en stel replicatie-instellingen in

Initialiseer AWS MGN in de regio waar de server zal draaien, definieer vervolgens de replicatie-instellingen zodat de golfuitvoering consistent blijft. Een stabiel sjabloon vermindert de variatie per server en maakt probleemoplossing herhaalbaar. Beschouw dit als uw standaard operationele procedure voor replicatie, vergelijkbaar met een gouden afbeelding in een gevirtualiseerde omgeving.

Stel de replicatie-instellingen vooraf in:

• Doel subnetstrategie en netwerkplaatsing
• Beveiligingsgroep basislijn voor gelanceerde instanties
• Opslaggedrag (volume mapping, versleuteling verwachtingen)
• Replicatiebeperking om productieverkeer te beschermen

Als je al weet dat de productie andere instellingen vereist dan de test, definieer die verschillen dan expliciet. Op die manier blijven testlanceringen representatief zonder de productienetwerken voortijdig bloot te stellen.

Installeer de agent en voltooi de initiële synchronisatie

Installeer de replicatieagent op de bronsserver en bevestig dat deze succesvol registreert. De initiële synchronisatie is waar instabiliteit je het meest kost, dus vermijd onnodige wijzigingen en houd de replicatiegezondheid nauwlettend in de gaten. Dit is ook waar teams profiteren van het documenteren van de "bekend goede" installatiestroom, zodat ze niet dezelfde problemen in elke golf oplossen.

Operationele richtlijnen:

• Houd de server stabiel tijdens de initiële replicatie (vermijd herstarts indien mogelijk)
• Monitor de replicatiestatus en los fouten onmiddellijk aan.
• Documenteer de installatiemethode zodat toekomstige golven consistent zijn.

Tijdens de initiële synchronisatie, monitor niet alleen de migratieconsole maar ook de serverprestaties. Replicatie-overhead kan opslagknelpunten of schijffouten onthullen die eerder verborgen waren in de on-prem omgeving.

Start een testinstance en valideer

Een testlancering verandert aannames in bewijs. Start de testinstance en valideer vervolgens de applicatiegezondheid van begin tot eind, niet alleen het opstarten. Gebruik een checklist zodat testen herhaalbaar is over servers en golven. Als eindgebruikers verbinding maken via TSplus Remote Access , neem een toegangspadcontrole op in de validatie. Consistentie is belangrijk omdat het je in staat stelt om resultaten tussen workloads te vergelijken en patronen te herkennen, zoals DNS-resolutieproblemen die meerdere servers beïnvloeden.

Minimale validatiechecklist:

• Opstarten voltooid en services starten schoon
• Applicatie rooktests slagen voor belangrijke workflows
• Authenticatie werkt (AD/LDAP/lokaal)
• Datapaden werken (DB-verbindingen, bestandsdeling, integraties)
• Geplande taken en achtergrondservices draaien zoals verwacht
• Logs en monitoringsignalen verschijnen waar uw operationele team ze verwacht

Voeg nog een stap toe die teams vaak overslaan: valideer hoe gebruikers daadwerkelijk toegang zullen krijgen tot de applicatie, inclusief interne routering, firewallregels en eventuele upstreamsystemen. Een server kan "gezond" zijn, maar in de praktijk onbereikbaar.

Start de overstap en rond af

Cutover is een gecontroleerde overschakeling, geen sprongetje in het duister. Bevries wijzigingen, wanneer mogelijk, voer de verkeersverplaatsing uit met behulp van het geplande mechanisme en valideer vervolgens met dezelfde checklist als bij het testen. Houd de rollback-eigendom expliciet zodat beslissingen snel zijn. Behandel dit als een herhaalbaar draaiboek: hoe minder je improviseert, hoe lager het risico.

Cutover-uitvoeringsessentials:

• Bevestig wijziging bevriezing en communicatieplan
• Start cutover-instantie en schakel verkeer om (DNS/LB/routering)
• Herhaal de validatielijst met extra aandacht voor gegevensintegriteit
• Pas rollback-triggers toe indien nodig en keer verkeer op een nette manier terug.
• Finalize cutover en verwijder of beëindig testbronnen

Onmiddellijk na de overstap, leg vast wat er in productie is veranderd (nieuwe IP's, nieuwe routes, nieuwe beveiligingsgroepsregels) en documenteer dit. Dit is de informatie die het operationele team nodig heeft wanneer er weken later iets misgaat.

Wat breekt meestal, en wat moet je direct na de overstap doen?

Netwerkuitvoer, DNS/AD-afhankelijkheden, en "lift-and-shift is niet gedaan"

De meeste fouten zijn afhankelijkheidsfouten. Replicatie heeft de neiging te breken op uitgaande en proxybeperkingen, terwijl het gedrag van de applicatie de neiging heeft te breken op identiteit, naamresolutie en certificaten. Zelfs wanneer de overstap succesvol is, is rehosting slechts de eerste mijlpaal, niet de eindtoestand. Zonder een tweede fase eindig je vaak met "in de cloud gehoste legacy" die meer kost en moeilijker te beheren is.

Meest voorkomende breekpunten:

• Uitgaande HTTPS geblokkeerd of gewijzigd door proxy TLS-inspectie
• DNS-resolutie wijzigingen (split-horizonproblemen, ontbrekende resolverregels)
• AD/LDAP bereikbaarheidstekorten vanuit de VPC
• Interne PKI-ketens ontbreken of worden niet vertrouwd in de nieuwe omgeving
• Hardcoded eindpunten en verouderde aannames over lokale netwerkpaden

Een eenvoudige mitigatie is om identiteit en DNS vroeg te testen met een pilotlancering. Als die fundamenten werken, wordt de rest van de applicatievalidatie veel voorspelbaarder.

Post-cutover stabilisatie: beveiliging, back-ups, monitoring, kosten

De eerste 48 uur na de overstap moeten prioriteit geven aan stabiliteit en controle. Zorg ervoor dat de werklast observeerbaar, herstelbaar en veilig beheerd is voordat je tijd besteedt aan diepere optimalisatie. Dit is ook waar je migratie op lange termijn succesvol is, omdat goede operaties op de tweede dag voorkomen dat er resultaten zijn van "we hebben het verplaatst, maar niemand wil het beheren".

Directe acties na de overstap:

• Bevestig dat monitoring/waarschuwing actief is en in beheer is
• Zorg ervoor dat back-ups zijn ingeschakeld en voltooi een herstelvalidatie
• Beperk beveiligingsgroepen en pas het principe van de minste privileges toe IAM
• Standaardiseer de patchingaanpak en administratieve toegang (auditbare paden)
• Begin met het optimaliseren van de grootte nadat je echte gebruiksgegevens hebt verzameld.
• Handhaaf tagging om "onbekende eigenaar" kostenafwijkingen te voorkomen

Zodra de stabiliteit is bewezen, plan een korte optimalisatiebeoordeling voor elke gemigreerde server. Zelfs een lichte controle van opslagtypes, keuze van instantiefamilie en strategie voor gereserveerde capaciteit kan de kosten aanzienlijk verlagen.

Waar past TSplus nadat u servers naar AWS heeft verplaatst?

Nadat Windows-werkbelastingen op AWS draaien, hebben veel teams nog steeds een eenvoudige manier nodig om Windows-toepassingen en -desktops aan gebruikers te publiceren zonder een zware VDI-stack te bouwen. TSplus Remote Access levert applicatiepublicatie en externe desktoptoegang voor Windows-servers in AWS, on-premise of hybride omgevingen, met eenvoudige administratie en voorspelbare licenties die passen bij MKB- en mid-marketoperaties.

Conclusie

Migreren van een on-premises server naar AWS is het meest succesvol wanneer het een herhaalbaar runbook volgt: kies de juiste migratiestrategie, valideer afhankelijkheden, replicate veilig, test realistisch en maak de overstap met duidelijke rollback-triggers. Zodra de productie stabiel is, verschuif de focus naar de operaties op de tweede dag: beveiligingsversterking, back-upvalidatie, monitoring en het optimaliseren van de grootte. Dit verandert een "verhuizing" in een betrouwbare, kostenbeheersbare platform.