Discovery, MGN, VMware Cloud আর 7 Rs

এই লেসন শেষে তুমি পারবে

• Migration-এর 7 Rs (retire, retain, relocate, rehost, replatform, repurchase, refactor) নাম ধরে বলতে, কোনটায় কী বদলায় বোঝাতে, আর প্রতিটার সাথে মানানসই AWS tool মেলাতে।
• AWS Application Discovery Service দিয়ে ডেটা সেন্টার সরানোর পরিকল্পনা করতে: Agentless Collector আর Discovery Agent-এর মধ্যে বেছে নিতে, লুকানো dependency খুঁজে বের করতে, আর server-গুলোকে application আর wave-এ সাজাতে।
• AWS Application Migration Service (MGN) কীভাবে server rehost করে বুঝিয়ে বলতে: replication agent, staging area, সারাক্ষণ চলা block-level replication, test launch, cutover, finalize আর archive, আর প্রতিটা ধাপে downtime আর টাকার হিসাব।
• MGN-কে Elastic Disaster Recovery, VM Import/Export আর VMware Cloud on AWS থেকে আলাদা করতে, আর প্রশ্নের keyword দেখে ঠিকটা বেছে নিতে।
• VM Import/Export দিয়ে OVA, VMDK, VHD আর raw image-কে AMI বানিয়ে ভেতরে আনতে, EC2 instance-কে আবার বাইরে পাঠাতে, আর এর সীমাগুলো জানতে।
• ২০২৪–২৬-এর পরিবর্তনগুলো জানতে: Migration Hub আর Application Discovery Service নতুন customer-এর জন্য বন্ধ, AWS Transform, MGN-এর নতুন নাম, Amazon EVS, আর Amazon Linux 2-এর support শেষ; আর পরীক্ষায় এখনও কোন উত্তর চায়।

#Server সরাতে কেন পরিকল্পনা লাগে

একটা server AWS-এ নেওয়া সহজ। পুরো একটা ডেটা সেন্টার সরানো সহজ না: ঢাকার একটা bank-এ হয়তো ৩০০টা server চলে, যার কয়েকটার কথা কেউ মনেই রাখেনি, কয়েকটা কেবল তখনই কাজ করে যখন আরেকটা server-এ পৌঁছানো যায়, আর কয়েকটার licence পুরোনো hardware-এর সাথে বাঁধা। এগুলো ভুল ক্রমে একটা একটা করে সরালে বেতনের দিনেই সব ভেঙে পড়ে।

তাই AWS একটা migration-কে তিন ভাগে ভাগ করে দেখে:

1. Assess: আমাদের কী আছে, AWS-এ এর খরচ কত পড়বে, সরানোটা লাভজনক কি না? (একটা business case: Migration Evaluator, Application Discovery Service।)
2. Mobilize: server আর dependency-র খুঁটিনাটি discovery, প্রতিটা application নিয়ে একটা সিদ্ধান্ত (নিচের 7 Rs), একটা landing zone (account, network, security), আর wave-এর পরিকল্পনা: কোন কোন application একসাথে সরবে।
3. Migrate and modernize: প্রতিটা wave ঠিক tool দিয়ে আসলে সরানো (server-এর জন্য MGN, database-এর জন্য DMS, লেসন ২৩.৩, বিশাল ডেটার জন্য Snowball বা DataSync, লেসন ২৩.৫), তারপর ধাপে ধাপে উন্নত করা।

পরীক্ষায় এটা তিনভাবে আসে: “কোন strategy” (7 Rs), “পরিকল্পনা কীভাবে করব” (Application Discovery Service), আর “server কীভাবে সরাব” (MGN, VM Import/Export, VMware Cloud on AWS)। এই লেসনও ঠিক এই ক্রমেই এগোবে।

#7 Rs: একটা application সরানোর সাতটা উপায়

প্রতিটা application-এর জন্য team সাতটা strategy-র একটা বেছে নেয়। এই তালিকা শুরু হয়েছিল Gartner-এর 5 Rs দিয়ে, তারপর AWS-এর 6 Rs, আর relocate যোগ হয়ে এখন 7 Rs। নিচে সবচেয়ে কম পরিবর্তন থেকে সবচেয়ে বেশি পরিবর্তনের ক্রমে সাজানো।

পরীক্ষা যে জোড়াগুলো নিয়ে খেলে:

• Rehost বনাম replatform। Rehost server-এর কিছুই বদলায় না: MGN পুরো disk, OS সহ, কপি করে। Replatform code রাখে কিন্তু নিচের platform বদলায়: VM-এ MySQL-এর বদলে managed database (RDS, লেসন ৭.১), বা হাতে বানানো Tomcat server-এর বদলে Elastic Beanstalk।
• Replatform বনাম refactor। Replatform একটা ছোট উন্নতি; refactor মানে নতুন design (একটা monolith ভেঙে Lambda function বা ECS service)। Refactor-এ শুরুতে খরচ সবচেয়ে বেশি, বেছে নেওয়া হয় যখন ব্যবসার এমন scale, গতি বা feature দরকার যা পুরোনো design দিতে পারে না।
• Rehost বনাম relocate। Rehost প্রতিটা server-কে একটা EC2 instance বানায়। Relocate VMware VM-কে AWS-এ চলা VMware-এ নিয়ে যায়: কোনো conversion নেই, একই vCenter, একই কাজের ধরন।
• Retire বনাম retain বনাম repurchase। Retire: কারও দরকার নেই। Retain: দরকার আছে, কিন্তু আপাতত যেখানে আছে সেখানেই। Repurchase: দরকার আছে, কিন্তু অন্যের SaaS হিসেবে।

নিজে চেষ্টা করো: নিচের প্রতিটা case-এ একটা দেখতে-একই-রকম ফাঁদ লুকানো। আগে একটা R বেছে নাও, তারপর পড়ো অন্যটা কেন ভুল।

#ধাপ ১: তোমার কাছে কী আছে, খুঁজে বের করো

#Discovery কেন সবার আগে

পুরোনো একটা spreadsheet দেখে বানানো migration plan তিনভাবে গোলমাল করে: তালিকায় না থাকা server পেছনে পড়ে থাকে, কোনো server যার ওপর নির্ভর করে সেটা ছাড়াই সরে যায়, আর প্রতিটা server-কে পুরোনো hardware-এর সমান বড় EC2 instance দেওয়া হয়, যদিও আগে সেটা ৫% CPU-তে চলত। Discovery মাপা ডেটা দিয়ে তিনটাই ঠিক করে।

AWS Application Discovery Service তোমার অন-প্রেমিসেস server-গুলোর তথ্য জোগাড় করে, যাতে migration-এর পরিকল্পনা করা যায়:

• Configuration: hostname, OS, CPU কয়টা, memory, disk, IP আর MAC address।
• Utilization: সময়ের সাথে CPU, memory, disk আর network-এর ব্যবহার, যাতে EC2 instance মাপমতো (right-size) বেছে নেওয়া যায়, হুবহু একই মাপে কপি না করে।
• Dependency: কোন process চলে, আর কোন server কোন server-এর সাথে কোন port-এ কথা বলে। পরিকল্পনার জন্য এটাই সবচেয়ে জরুরি, কারণ নির্ভরশীল server-গুলো একই wave-এ সরাতে হয়।

ডেটা encrypt অবস্থায় জমা থাকে তোমার home Region-এ, আর দেখা যায় AWS Migration Hub-এ, যেখানে server-গুলোকে application হিসেবে group করে wave সাজানো হয়। ডেটা export-ও করা যায় (continuous export agent-এর ডেটা S3-এ পাঠায়, সেখানে Athena দিয়ে query করা যায়), কিংবা আগে থেকে থাকা তালিকা CSV দিয়ে import করেও শুরু করা যায়।

#Agentless Collector বনাম Discovery Agent

তথ্য জোগাড়ের দুটো উপায় আছে, আর পরীক্ষা ঠিক এই পার্থক্যটাই ধরে:

Slide-এর পুরোনো Agentless Discovery Connector-এর জায়গা নিয়েছে Agentless Collector; ১৭ নভেম্বর ২০২৫ থেকে service-টা Discovery Connector-এর ডেটা আর নেয় না।

#ধাপ ২: AWS Application Migration Service (MGN) দিয়ে rehost

#MGN জিনিসটা কী

AWS Application Migration Service (MGN) হলো rehost (lift-and-shift) migration-এর জন্য AWS-এর প্রধান tool। এটা physical server, যেকোনো hypervisor-এর (VMware, Hyper-V ইত্যাদি) virtual machine আর অন্য cloud-এর server নিয়ে এমন EC2 instance বানায় যা AWS-এ নিজে থেকেই boot করে, application-এর code-এ কোনো পরিবর্তন ছাড়া। Windows আর Linux-এর অনেক version, আর তাদের ওপর চলা database আর application (SAP, Oracle, SQL Server খুব চলে) এটা সমর্থন করে।

পরীক্ষার জন্য এর বংশতালিকা জরুরি:

• CloudEndure Migration: ২০১৯-এ AWS যে কোম্পানি কিনেছিল; MGN হলো তার replication প্রযুক্তির “AWS সংস্করণ”।
• AWS Server Migration Service: পুরোনো, শুধু VM-এর জন্য, snapshot-ভিত্তিক tool। AWS এটা ৩১ মার্চ ২০২২-এ বন্ধ করে দিয়েছে; জায়গা নিয়েছে MGN।
• AWS Transform MGN: জুন ২০২৬ থেকে একই service-এর নতুন নাম, কারণ এটাই AWS Transform-এর পেছনের replication engine। Console, API আর aws mgn command একই আছে, আর পরীক্ষার প্রশ্নে এখনও লেখা থাকে “Application Migration Service (MGN)”।

#Replication কীভাবে চলে

1. প্রতিটা source server-এ AWS Replication Agent install করো। এটা TCP 443 দিয়ে MGN service-এর সাথে কথা বলে।
2. তোমার বেছে দেওয়া একটা subnet-এ MGN একটা staging area বানায়: কয়েকটা ছোট, সস্তা replication server আর কম দামের EBS volume, প্রতিটা source disk-এর জন্য একটা করে। পুরো মাপের server চলে না; এ কারণেই replication সস্তা।
3. প্রথম sync: agent প্রতিটা disk-এর প্রতিটা block TCP 1500 দিয়ে replication server-এ পাঠায়, পথে encrypt করা অবস্থায়। পুরো সময় source server কাজ করে যায়।
4. সারাক্ষণ block-level replication: প্রথম sync-এর পর শুধু বদলানো block যায়, তাই staging-এর কপি source থেকে মাত্র কয়েক সেকেন্ড পিছিয়ে থাকে।
5. Launch করার সময় MGN disk-গুলো convert করে, যাতে EC2-তে boot হয় (driver, boot loader, network), আর তোমার launch setting অনুযায়ী instance বানায়।

#Test, cutover, finalize

1. ১. Launch setting ঠিক করো

   প্রতিটা source server-এর একটা EC2 launch template থাকে (subnet, security group, instance type, IAM role, tag; launch template লেসন ৪.৩-এ বোঝানো আছে), আর থাকে MGN-এর নিজের কিছু option, যেমন right-sizing (source-এর CPU আর memory দেখে instance type বেছে নেওয়া) আর post-launch action: নতুন instance-এ চলা Systems Manager document, যেমন CloudWatch agent বসানো বা অন-প্রেমিসেসের পুরোনো tool সরানো।

2. ২. Test instance চালু করো

   Test launch সর্বশেষ replicate হওয়া অবস্থা থেকে EC2 instance বানায়, এর মধ্যেও replication চলে আর source ব্যবহারকারীদের সামলায়। Team application যাচাই করে। Test ব্যর্থ হলে (ভুল subnet, security group-এ rule নেই, পুরোনো hardware-এ বাঁধা licence) এখনই ঠিক করো: কিছু হারায়নি, কোনো ব্যবহারকারী টেরও পায়নি।

3. ৩. Ready চিহ্ন দাও, তারপর cutover

   Test পাস হলে server-কে ready for cutover চিহ্ন দেওয়া হয়। Cutover-এর সময়টুকুতে: source-এ application বন্ধ করো, শেষ block-গুলো আসতে দাও, cutover instance চালু করো, DNS বা load balancer ঘুরিয়ে দাও। Downtime শুধু এই সময়টুকু, সাধারণত কয়েক মিনিট।

4. ৪. Finalize আর archive

   নতুন instance কিছুদিন ভালোভাবে চললে cutover finalize করো: replication থামে আর MGN staging-এর resource মুছে দেয়, ফলে তার খরচও থামে। তারপর server-কে archive চিহ্ন দাও। Finalize না করা পর্যন্ত অক্ষত source-টাই তোমার rollback-এর পথ।

#MGN-এর খরচ

প্রতিটা source server পায় ২,১৬০ ঘণ্টা বিনা পয়সার MGN, মানে টানা replication-এর হিসাবে ৯০ দিন, গোনা শুরু হয় agent install করার মুহূর্ত থেকে। বেশিরভাগ server এর অনেক আগেই শেষ হয়ে যায়। এরপর MGN replication-এর জন্য প্রতি server, প্রতি ঘণ্টা হিসাবে টাকা নেয়। Service fee-এর বাইরে, এটা যে AWS resource বানায় তার দাম সব সময়ই দিতে হয়: replication server আর staging-এর EBS volume, আর test ও cutover-এর EC2 instance ও তাদের volume। দেরি না করে finalize করাই staging-এর খরচ থামানোর উপায়।

#MGN নাকি Elastic Disaster Recovery?

MGN আর AWS Elastic Disaster Recovery (DRS) (লেসন ২৩.২) একই CloudEndure replication প্রযুক্তির ওপর দাঁড়িয়ে: agent, staging area, সারাক্ষণ block-level replication, EC2-তে launch। কিন্তু কাজ আলাদা।

Notes-এর exam keyword “DR-এর জন্য physical/virtual server AWS-এ migrate করো” দুটো জিনিস মিশিয়ে ফেলে: সরানো মানে MGN, ফিরে আসার প্রস্তুতি মানে DRS।

#VM Import/Export

VM Import/Export তোমার virtualization environment আর EC2-এর মধ্যে virtual machine-এর image আনা-নেওয়া করে, S3-এর মাধ্যমে। Feature-টা বিনা পয়সার; টাকা দিতে হয় শুধু S3 storage আর এর বানানো EBS snapshot ও instance-এর জন্য।

Import (ec2 import-image, বা শুধু একটা disk হলে import-snapshot):

• যে format নেয়: OVA (পুরো একটা VM, একাধিক disk থাকতে পারে), stream-optimized VMDK (VMware vSphere), VHD আর VHDX (Hyper-V, আর Azure ও Citrix Xen) আর raw image।
• ধাপ: hypervisor থেকে VM export করো → file-টা S3-এ upload করো → vmimport নামের service role দিয়ে import-image ডাকো, যে role bucket পড়তে পারে → service convert করে → তুমি পাও একটা AMI (বা একটা EBS snapshot), আর তা থেকে instance চালু করো (AMI, লেসন ৪.৩)।
• সীমা: শুধু সমর্থিত তালিকার OS (Windows Server আর Linux-এর বেশিরভাগ version); physical-to-virtual conversion দিয়ে বানানো VM চলবে না; Arm-ভিত্তিক image চলবে না।

Export (ec2 create-instance-export-task, বা একটা AMI export):

• যে format-এ বের হয়: OVA, VMDK বা VHD, একই account-এর একটা S3 bucket-এ (SSE-S3 বা encrypt ছাড়া; SSE-KMS না)।
• যা export করা যায় না: AWS-এর দেওয়া third-party software থাকা instance (AWS AMI-র Windows বা SQL Server, Marketplace image), encrypt করা EBS snapshot থাকা instance, একাধিক disk বা একাধিক network interface থাকা instance, বা 1 TiB-এর বড় volume।

MGN-এর বদলে কখন এটা: একবারের একটা image (vendor-এর OVA হিসেবে পাঠানো appliance, অন-প্রেমিসেসে বানানো golden VM), AWS-এ রাখা VM image-এর একটা DR ভান্ডার (slide-এর use case), বা কোনো workload আবার অন-প্রেমিসেসে ফিরিয়ে নেওয়া। Server যদি চালু থাকে, সংখ্যায় অনেক হয়, physical হয়, বা cutover পর্যন্ত চালু রাখতেই হয়, তাহলে MGN।

#VMware Cloud on AWS

#জিনিসটা কী

অনেক কোম্পানি বছরের পর বছর VMware চালায়: vSphere (hypervisor আর তার host), vCenter (পরিচালনা), vSAN (storage) আর NSX (networking), আর তাদের IT team এই tool-গুলো হাতের তালুর মতো চেনে। VMware Cloud on AWS ঠিক এই VMware stack-টাই একটা software-defined data center (SDDC) হিসেবে চালায়, একটা AWS Region-এ AWS-এর নিজস্ব bare-metal host-এর ওপর। Stack চালায় VMware (এখন Broadcom); hardware দেয় AWS।

• একই tool, নতুন training লাগে না। Team SDDC চালায় সেই vCenter দিয়েই, যেটা প্রায়ই অন-প্রেমিসেসের vCenter-এর সাথে জোড়া থাকে।
• কোনো conversion নেই। VM সরে VMware VM হিসেবেই। VMware HCX দিয়ে এগুলো vMotion-এ live সরানো যায় (reboot নেই, stretched network-এ একই IP address) অথবা একসাথে অনেকগুলো (আগে replicate, তারপর পরিকল্পিত সময়ে একবার reboot)।
• পাশেই AWS service। SDDC তোমার নিজের account-এর একটা VPC-র সাথে জোড়া, তাই VM-গুলো private পথে S3, RDS, FSx, Redshift-সহ অন্য service ব্যবহার করতে পারে (FSx-এর client তালিকাতেও VMware Cloud on AWS আছে, লেসন ১২.২)।

Slide-এর ক্রমে ব্যবহার: vSphere workload AWS-এ migrate করা (এটাই relocate R), ডেটা সেন্টার বাড়ানো আর private ও public VMware cloud জুড়ে production চালানো (hybrid), আর AWS-এ একটা disaster recovery site রাখা।

#প্রশ্ন দেখে tool বেছে নেওয়া

পুরো একটা উত্তরে সাধারণত কয়েকটা মিলে যায়: Application Discovery Service দিয়ে খুঁজে বের করো, application server MGN দিয়ে rehost করো, database DMS দিয়ে সরাও, file archive Snowball-এ পাঠাও, আর wave চলার সময় দুই জায়গা জুড়ে রাখো Site-to-Site VPN বা Direct Connect দিয়ে।

#কোথায় গোলমাল হয়

• লুকানো dependency। কোনো server যাকে ডাকে (SMS gateway, licence server, file share) তাকে ছাড়া সরালে production-এ ভেঙে পড়ে। মাসিক আর ত্রৈমাসিক কাজ ধরা পড়ার মতো লম্বা সময় Discovery Agent চালাও, তারপর নির্ভরশীল server একই wave-এ সরাও।
• মাপ কপি করা, মাপা না। পুরোনো ৩২-core host-কে ৩২ vCPU-র instance বানালে টাকা নষ্ট। Utilization-এর ডেটা আর MGN-এর right-sizing ব্যবহার করো, cutover-এর পর আবার ঠিক করো।
• ভুল launch setting। Default launch template instance-কে ভুল subnet বা security group-এ বসায়; test launch এটা ধরে ফেলে। Test কখনো বাদ দিও না।
• Cutover-এর সময় replication lag। ধীর বা ভাগাভাগির link, কিংবা source যত দ্রুত লেখে link তত দ্রুত বইতে না পারলে lag বেশি থাকে, ফলে cutover-এর সময় লম্বা হয়। কয়েক সপ্তাহ আগে sync শুরু করো, bandwidth বাড়াও (VPN বা Direct Connect), শান্ত দিনে cutover করো।
• Licence আর hardware-এর বাঁধন। MAC address, dongle বা host ID-তে বাঁধা software EC2-তে চালু হতে রাজি নাও হতে পারে। Cutover-এর আগে vendor-এর সাথে কথা বলো; নিজের licence আনার নিয়ম থাকলে Dedicated Host ভেবে দেখো।
• Finalize করতে ভুলে যাওয়া। Cutover-এর পরও finalize না করা পর্যন্ত staging server আর volume টাকা খেতে থাকে, আর replicate হতে থাকা server-এর MGN-এর ৯০ দিনের বিনা পয়সার সময়ও ফুরিয়ে যায়।
• ভুল tool। Physical server-এর জন্য VM Import (সমর্থিত না), Hyper-V-এর জন্য VMware Cloud on AWS (VMware লাগে), একবারের migration-এর জন্য DRS (ওটা recovery-র জন্য), নতুন design-এ Server Migration Service (বন্ধ হয়ে গেছে)।

#নিজে করে দেখো

এই command-গুলো AWS CLI v2-এর। Account, ID আর নাম উদাহরণ। aws mgn command চালানোর আগে Region-এ একবার (console থেকে) MGN initialize করে নিতে হয়।

# 1. Application Discovery Service: see the agents and start collecting
aws discovery describe-agents --region ap-southeast-1
# { "agentsInfo": [ { "agentId": "o-0123456789abcdef0", "hostName": "payroll-app",
#     "agentType": "EC2", "health": "HEALTHY", "collectionStatus": "STOPPED" }, ... ] }
aws discovery start-data-collection-by-agent-ids --agent-ids o-0123456789abcdef0
aws discovery start-continuous-export      # agent data streams to S3, ready for Athena
# { "exportId": "export-1234567890abcdef0", "s3Bucket": "aws-application-discovery-service-111122223333-example",
#   "dataSource": "AGENT", "startTime": "2026-11-01T10:00:00Z" }

# 2. MGN: list source servers and their lifecycle state
aws mgn describe-source-servers --region ap-southeast-1 \
  --query 'items[].{id:sourceServerID,host:sourceProperties.identificationHints.hostname,state:lifeCycle.state}'
# [ { "id": "s-1234567890abcdef0", "host": "results-01", "state": "READY_FOR_TEST" } ]

# 3. Launch a test instance, then mark the server ready for cutover once the test passes
aws mgn start-test --source-server-ids s-1234567890abcdef0
aws mgn change-server-life-cycle-state --source-server-id s-1234567890abcdef0 \
  --life-cycle state=READY_FOR_CUTOVER

# 4. Cut over, then (after a quiet week) finalize and archive
aws mgn start-cutover --source-server-ids s-1234567890abcdef0
aws mgn finalize-cutover --source-server-id s-1234567890abcdef0
aws mgn mark-as-archived --source-server-id s-1234567890abcdef0

# 5. VM Import: bring an OVA from S3 in as an AMI and watch the task
aws ec2 import-image --description "billing appliance" \
  --disk-containers '[{"Format":"ova","UserBucket":{"S3Bucket":"vm-images-example","S3Key":"billing.ova"}}]'
# { "ImportTaskId": "import-ami-0123456789abcdef0", "Status": "active", "Progress": "1" }
aws ec2 describe-import-image-tasks --import-task-ids import-ami-0123456789abcdef0 \
  --query 'ImportImageTasks[0].[Status,StatusMessage,ImageId]'
# [ "completed", null, "ami-0abcd1234example" ]

# 6. VM Export: send an imported instance back out as an OVA
aws ec2 create-instance-export-task --instance-id i-0abcd1234example --target-environment vmware \
  --export-to-s3-task DiskImageFormat=VMDK,ContainerFormat=ova,S3Bucket=vm-images-example,S3Prefix=exports/
# { "ExportTask": { "ExportTaskId": "export-i-0123456789abcdef0", "State": "active" } }

কাজ শেষে MGN-এ test server finalize বা disconnect করো, আর test-এর AMI ও snapshot মুছে দাও, নইলে staging-এর resource-এর bill আসতেই থাকবে।

#সারসংক্ষেপ

মনে রাখার কথা

• 7 Rs: retire (বন্ধ করো), retain (আপাতত রেখে দাও), relocate (VMware থেকে VMware Cloud on AWS), rehost (MGN দিয়ে lift and shift), replatform (একটা অংশ RDS বা Beanstalk দিয়ে বদল), repurchase (SaaS কেনো), refactor (cloud-native করে নতুন করে বানাও)।
• Application Discovery Service সরানোর পরিকল্পনা করে: configuration, utilization, আর Discovery Agent থাকলে process আর network dependency; Agentless Collector agent ছাড়াই VMware-এর তালিকা আর performance দেয়। ফল group করা হয় Migration Hub-এ।
• MGN physical, virtual আর cloud server EC2-তে rehost করে: agent → staging area (সস্তা replication server আর EBS) → সারাক্ষণ block-level replication → test → cutover (কয়েক মিনিটের downtime) → finalize → archive। প্রতি server ৯০ দিন বিনা পয়সায়; staging আর instance-এর bill আলাদা।
• MGN এসেছে CloudEndure Migration আর Server Migration Service-এর জায়গায় (মার্চ ২০২২-এ বন্ধ); জুন ২০২৬ থেকে এর আরেক নাম AWS Transform MGN। MGN সরায়, DRS সুরক্ষা দেয়: প্রযুক্তি একই, কাজ আলাদা।
• VM Import/Export S3-এ রাখা OVA, VMDK, VHD/VHDX আর raw image থেকে AMI বানায়, আর instance-কে OVA, VMDK বা VHD হিসেবে export করে; physical-to-virtual image চলে না, AWS-licence-এর Windows export হয় না।
• VMware Cloud on AWS AWS-এর bare metal-এ vCenter, vSphere, vSAN আর NSX রেখে দেয়, HCX আর vMotion দিয়ে VM live সরায়, আর “VMware tool রেখে দাও, training না”-এর উত্তর এটাই। AWS ২০২৪-এ এটা বিক্রি বন্ধ করেছে; Amazon EVS (২০২৫) তোমার VPC-তে VMware Cloud Foundation চালায়।
• নভেম্বর ২০২৫ থেকে Migration Hub আর Application Discovery Service নতুন customer-এর জন্য বন্ধ, উত্তরসূরি AWS Transform; তবু discovery-র প্রশ্নে পরীক্ষার উত্তর এখনও Application Discovery Service।

নিজেকে যাচাই করো: server migration৩০টি প্রশ্ন