۱۹ فروردین ۱۴۰۵۱۲ دقیقه مطالعه
مهاجرت به فضای ابری؛ نکاتی که قبل از شروع باید بدانید
قبل از مهاجرت به فضای ابری باید Workloadها، وابستگیها، هزینه، امنیت، روش مهاجرت و برنامه Rollback را مشخص کنید. این راهنما مسیر درست Cloud Migration را توضیح میدهد.
مهاجرت به فضای ابری در ظاهر ساده به نظر میرسد:
سرورها را از دیتاسنتر فعلی برداریم، روی Cloud اجرا کنیم و تمام.
اما بخش سخت پروژه معمولاً همان «انتقال» نیست.
سؤالهای مهمتر قبل از آن شروع میشوند:
چه چیزی باید منتقل شود؟
چه چیزی بهتر است فعلاً همانجا بماند؟
کدام سیستم فقط باید جابهجا شود و کدامیک نیاز به بازطراحی دارد؟
هزینه واقعی محیط جدید چقدر خواهد بود؟
اگر هنگام Cutover مشکلی پیش آمد، راه برگشت چیست؟
و بعد از مهاجرت، چه کسی قرار است این زیرساخت جدید را مدیریت کند؟
AWS، Microsoft و Google هر سه در چارچوبهای رسمی مهاجرت خود تقریباً روی یک اصل مشترک تأکید دارند: قبل از انتقال Workloadها باید محیط فعلی را بشناسید، وابستگیها را مشخص کنید، معماری مقصد را آماده کنید و برای مهاجرت برنامه داشته باشید.
Cloud قرار نیست مشکلات معماری، امنیتی یا عملیاتی سیستم فعلی را با خودش حل کند.
گاهی فقط همان مشکلات را به آدرس جدیدی منتقل میکند.
اول مشخص کنید چرا میخواهید به Cloud بروید
«میخواهیم Cloud شویم» هدف نیست.
قبل از انتخاب Provider یا معماری، باید مشخص شود چه نتیجهای از مهاجرت انتظار دارید.
مثلاً:
- میخواهید هزینه خرید و نگهداری سختافزار کمتر شود؟
- به ظرفیت بیشتری در زمان افزایش ترافیک نیاز دارید؟
- Disaster Recovery فعلی کافی نیست؟
- راهاندازی Environment جدید بیش از حد زمان میبرد؟
- میخواهید از Managed Serviceها استفاده کنید؟
- قرار است چند شعبه یا تیم از یک زیرساخت مشترک استفاده کنند؟
- یا دیتاسنتر فعلی دیگر پاسخگوی رشد کسبوکار نیست؟
دلیل مهاجرت روی تصمیمهای بعدی اثر مستقیم دارد.
اگر هدف شما Scalability باشد، انتقال ساده چند VM ممکن است ارزش چندانی ایجاد نکند.
اگر هدف خروج سریع از یک دیتاسنتر باشد، شاید Rehost کاملاً منطقی باشد.
و اگر مشکل اصلی یک نرمافزار قدیمی و سختنگهداری است، ممکن است بخشی از برنامه به Modernization نیاز داشته باشد.
قبل از انتخاب Cloud، دلیل رفتن به Cloud را مشخص کنید.
همهچیز را به Cloud نبرید فقط چون میتوانید
یکی از مهمترین تصمیمهای Cloud Migration این است که بفهمیم هر Workload چه سرنوشتی باید داشته باشد.
AWS این تصمیمها را در قالب 7R دستهبندی میکند:
Rehost
نرمافزار تقریباً با همان ساختار فعلی به Cloud منتقل میشود.
همان چیزی که معمولاً به آن Lift and Shift میگوییم.
این روش میتواند سریعتر و کمتغییرتر باشد، اما معمولاً تمام قابلیتهای Cloud-native را استفاده نمیکند.
Replatform
سیستم منتقل میشود، اما در همان مسیر بعضی بخشها بهینه میشوند.
مثلاً Database نصبشده روی VM به یک Managed Database منتقل شود.
در این حالت نرمافزار کاملاً بازنویسی نمیشود، اما بخشی از مسئولیت عملیاتی کمتر خواهد شد.
Refactor / Re-architect
معماری برنامه تغییر میکند تا بهتر از قابلیتهای Cloud استفاده کند.
این مسیر میتواند انعطاف و Scalability بیشتری ایجاد کند، اما هزینه، زمان و پیچیدگی بیشتری هم دارد.
Repurchase
بهجای ادامه استفاده از نرمافزار فعلی، یک محصول SaaS یا راهکار آماده جایگزین آن میشود.
Retain
فعلاً سیستم منتقل نمیشود.
گاهی بهدلیل هزینه، محدودیت فنی، Compliance، وابستگی یا اولویت پایین، بهترین تصمیم همین است.
Retire
سیستمی که دیگر ارزش واقعی ندارد کنار گذاشته میشود.
این مرحله بیشتر از چیزی که به نظر میرسد مهم است. Cloud Migration فرصت خوبی است برای اینکه سرورها، نرمافزارها و سرویسهایی را که سالها فقط از روی عادت روشن ماندهاند دوباره بررسی کنیم.
Relocate
زیرساخت تقریباً بدون تغییر در Workloadها به محیط دیگری منتقل میشود؛ مثلاً در سناریوهای خاص مجازیسازی.
نکته مهم اینجاست:
برای تمام سیستمها یک R انتخاب نکنید.
ممکن است CRM شما Replatform شود، یک سامانه قدیمی Retain بماند، چند VM Rehost شوند و نرمافزاری که دیگر کسی استفاده نمیکند Retire شود.
مهاجرت خوب معمولاً یک تصمیم واحد نیست؛ مجموعهای از تصمیمهای Workload به Workload است.
قبل از Migration یک Inventory واقعی بسازید
اگر نمیدانید چه چیزی دارید، نمیتوانید برای انتقالش برنامه درستی بسازید.
Inventory نباید فقط فهرست سرورها باشد.
برای هر Workload بهتر است حداقل این اطلاعات روشن شود:
- کاربرد سیستم چیست؟
- Owner آن چه تیم یا فردی است؟
- Production است یا Development/Test؟
- روی چه Server، Database و Storageای اجرا میشود؟
- چه دادهای نگهداری میکند؟
- میزان CPU، RAM، Storage و Network مصرفی آن چقدر است؟
- SLA موردنیاز چیست؟
- چه Backup و DRای دارد؟
- چه نرمافزارها یا Licenseهایی به آن وابستهاند؟
- چه سیستمهایی به آن وصل هستند؟
Microsoft در Cloud Adoption Framework تأکید میکند که Assessment قبل از Migration باید معماری، Performance، Security، Code، Database و وابستگیهای Workload را پوشش دهد.
Google Cloud نیز Discovery و ساخت Inventory کامل را یکی از اولین مراحل رسمی مهاجرت میداند.
این مرحله شاید هیجانانگیزترین قسمت Cloud Migration نباشد، اما معمولاً همان جایی است که جلوی غافلگیریهای بعدی را میگیرد.
Dependencyها را قبل از Cutover پیدا کنید، نه بعد از آن
فرض کنید یک Application Server را منتقل کردهاید.
همهچیز هم در ظاهر درست اجرا میشود.
بعد مشخص میشود برنامه برای Authentication به Active Directory داخل شبکه قدیمی وابسته است.
یک Scheduled Job باید به File Server دیگری دسترسی داشته باشد.
Database از IP مشخصی Connection قبول میکند.
یا سیستم دیگری هر شب اطلاعاتش را مستقیماً از همان Database میخواند.
اینها Dependencyهایی هستند که ممکن است در فهرست ساده سرورها دیده نشوند.
Dependency Mapping باید ارتباط میان این موارد را روشن کند:
- Applicationها
- Databaseها
- APIها
- File Shareها
- Identity
- DNS
- Firewall Ruleها
- External Serviceها
- Scheduled Jobها
- Message Queueها
- Monitoring
- Backup
- و ارتباطات شبکه
این Mapping روی ترتیب Migration هم اثر میگذارد.
اگر سه سیستم به یک Database مشترک وابستهاند، شاید نتوان آنها را در سه Wave کاملاً مستقل منتقل کرد.
به همین دلیل Google Cloud قبل از Wave Planning، Catalog Workloadها و Dependency Mapping را توصیه میکند.
Landing Zone را قبل از Workload آماده کنید
یکی از اشتباهات رایج این است که ابتدا VMها ساخته شوند و بعد درباره Structure، Security و Governance تصمیم بگیریم.
محیط مقصد قبل از Migration باید یک Foundation مشخص داشته باشد.
در ادبیات Cloud معمولاً از Landing Zone برای این Foundation استفاده میشود.
Landing Zone فقط یک Network نیست.
بسته به سازمان میتواند شامل این موارد باشد:
- Identity و Access Management
- Account / Subscription Structure
- Network Architecture
- VPN یا ارتباط Hybrid
- DNS
- Firewall
- Logging
- Monitoring
- Security Baseline
- Policyها
- Encryption
- Resource Naming
- Tagging
- Backup
- Budget و Cost Control
Microsoft، Landing Zone را Foundationای برای Governance، Security و Scale محیط Cloud تعریف میکند و توصیه میکند این استانداردها قبل از ورود Workloadها مشخص شوند.
یعنی قبل از اینکه اولین سرور Production را منتقل کنیم، بهتر است بدانیم:
- چه کسی Administrator است؟
- چه کسی فقط Read دارد؟
- Logها کجا جمع میشوند؟
- Resourceها چطور Tag میشوند؟
- Budget Alert داریم یا نه؟
- Backup Policy چیست؟
- Production و Test چطور از هم جدا میشوند؟
Cloud بدون Governance خیلی سریع میتواند از یک زیرساخت انعطافپذیر به یک اتاق شلوغ تبدیل شود.
هزینه Cloud را با قیمت یک VM مقایسه نکنید
یکی از جذابیتهای Cloud مدل پرداخت بر اساس مصرف است.
اما همین ویژگی میتواند محاسبه هزینه را هم پیچیده کند.
هزینه واقعی Workload فقط قیمت Compute نیست.
بسته به معماری باید موارد دیگری را هم در نظر گرفت:
- Storage
- Backup
- Snapshot
- Database
- Load Balancer
- Public IP
- Network Traffic
- Data Transfer / Egress
- Monitoring و Log
- Security Serviceها
- Support Plan
- Managed Serviceها
- Licenseها
- Disaster Recovery
- و حتی زمان تیم عملیاتی
به همین دلیل AWS در Assessment رسمی مهاجرت روی Total Cost of Ownership یا TCO تأکید دارد و Microsoft هم در Cloud Adoption Plan پیشنهاد میکند Estimated Workload Cost و Operational Cost از قبل ثبت شوند.
همچنین Sizing مقصد نباید صرفاً از روی ظرفیت سختافزار فعلی انجام شود.
اگر یک سرور On-premises هشت Core دارد، معنیاش این نیست که در Cloud هم دقیقاً به هشت vCPU نیاز دارید.
باید Usage واقعی را ببینید.
ممکن است سرور فعلی سالها Oversize بوده باشد.
Cloud زمانی از نظر مالی بهتر کار میکند که منابع را بر اساس مصرف واقعی طراحی و بعد از Migration هم مرتب Optimize کنیم.
Security از روز اول، نه بعد از Migration
Cloud خودش محیط را امن نمیکند.
Provider امنیت زیرساخت Cloud را مدیریت میکند، اما نحوه استفاده شما از Resourceها همچنان اهمیت دارد.
قبل از Migration باید حداقل درباره این موارد تصمیم داشته باشید:
- چه کسی به محیط Cloud دسترسی دارد؟
- MFA کجا اجباری است؟
- Permissionها چطور محدود میشوند؟
- Service Accountها چگونه مدیریت میشوند؟
- Secretها کجا نگهداری میشوند؟
- داده در Transit و At Rest چطور محافظت میشود؟
- Network Segmentation چگونه است؟
- Logهای امنیتی کجا جمع میشوند؟
- Incident Response چه مسیری دارد؟
- و اطلاعات حساس از نظر Compliance یا Data Residency کجا اجازه ذخیرهشدن دارند؟
Microsoft در Cloud Adoption Framework صریحاً توصیه میکند Security در تمام مراحل Adoption وارد طراحی شود، نه اینکه بعداً به محیط اضافه شود.
همچنین Landing Zone باید از ابتدا Guardrailهایی داشته باشد تا همه Workloadهای بعدی از یک حداقل استاندارد امنیتی پیروی کنند.
Data Residency و Compliance را زود مشخص کنید
همه دادهها را نمیتوان بدون بررسی به هر Region یا Providerی منتقل کرد.
اطلاعات مالی، اطلاعات شخصی، Health Data، Contract Data یا دادههایی که تحت الزامات خاص صنعتی هستند ممکن است محدودیتهایی داشته باشند.
قبل از Migration باید مشخص شود:
- داده دقیقاً در چه Regionای ذخیره خواهد شد؟
- Backup در کدام Region قرار میگیرد؟
- Provider یا سرویس موردنظر چه Complianceهایی دارد؟
- چه دادهای Encryption نیاز دارد؟
- و سیاست نگهداری یا حذف اطلاعات چیست؟
اگر این سؤالها بعد از انتخاب معماری مطرح شوند، ممکن است مجبور شوید بخشی از طراحی را دوباره انجام دهید.
Performance فعلی را قبل از انتقال اندازه بگیرید
اگر Baseline نداریم، بعد از Migration نمیتوانیم بفهمیم نتیجه بهتر شده یا بدتر.
قبل از انتقال بهتر است Performance فعلی ثبت شود.
مثلاً:
- Response Time
- CPU
- Memory
- Disk IOPS
- Network Throughput
- Database Latency
- Peak Traffic
- Concurrent Users
- Error Rate
- Availability
- و زمان اجرای Jobهای مهم
بعد از Migration همین معیارها دوباره اندازهگیری میشوند.
این مقایسه خیلی مهمتر از جمله ساده «سیستم روی Cloud بالا آمد» است.
Migration زمانی موفق است که Workload در مقصد طبق نیاز کسبوکار کار کند.
RTO و RPO را قبل از Backup Strategy مشخص کنید
«Backup داریم» بهتنهایی کافی نیست.
دو سؤال مهم وجود دارد:
RPO — Recovery Point Objective
در بدترین حالت چقدر Data Loss قابل قبول است؟
پنج دقیقه؟
یک ساعت؟
یک روز؟
RTO — Recovery Time Objective
اگر سیستم از دسترس خارج شد، حداکثر چقدر زمان داریم که آن را برگردانیم؟
پنج دقیقه؟
دو ساعت؟
یک روز؟
جواب این سؤالها تعیین میکند Backup، Replication و Disaster Recovery چگونه طراحی شوند.
سامانه حسابداری و یک سایت آرشیوی لزوماً به یک DR Strategy نیاز ندارند.
قبل از Migration باید این تفاوت مشخص باشد.
هیچ Cutover مهمی بدون Rollback Plan
یکی از مهمترین توصیههای Google Cloud برای Migration این است که برای مراحل مهاجرت Rollback Strategy وجود داشته باشد و این Strategy قبل از نیاز واقعی تست شود.
فرض کنید در شب Cutover:
- Data Sync کامل نشود.
- Performance مقصد پایین باشد.
- DNS طبق انتظار تغییر نکند.
- Authentication مشکل داشته باشد.
- Integration یکی از سیستمها قطع شود.
سؤال این نیست که «آیا مشکلی پیش میآید؟»
سؤال حرفهای این است:
اگر مشکل پیش آمد، در چه نقطهای تصمیم میگیریم برگردیم و دقیقاً چطور برمیگردیم؟
برای مراحل حساس بهتر است قبل از شروع مشخص شود:
- Go / No-Go Criteria چیست؟
- چه کسی تصمیم نهایی را میگیرد؟
- حداکثر زمان قابل قبول برای هر مرحله چقدر است؟
- چه زمانی Rollback شروع میشود؟
- Data ایجادشده در مقصد هنگام برگشت چه میشود؟
- و Source Environment تا چه زمانی قابل استفاده باقی میماند؟
Rollback Plan چیزی نیست که ساعت دو صبح و وسط Outage طراحی شود.
اولین Migration را با مهمترین سیستم شرکت شروع نکنید
Pilot برای یادگیری است.
بهتر است Workload اول:
آنقدر واقعی باشد که معماری و فرایند Migration را تست کند،
اما آنقدر Critical نباشد که هر مشکل کوچک تبدیل به بحران سازمانی شود.
Google Cloud پیشنهاد میکند Proof of Concept یا Pilot با معیارهای موفقیت مشخص اجرا شود تا Feasibility، Downtime، Performance، Security، Cost و Rollback قبل از Migration گستردهتر اعتبارسنجی شوند.
اولین Wave به شما کمک میکند بفهمید:
- Discovery چقدر دقیق بوده؟
- Landing Zone چه کمبودهایی دارد؟
- Automation کجا لازم است؟
- چه Skill Gapهایی در تیم وجود دارد؟
- Runbookها کامل هستند یا نه؟
- و زمان واقعی Migration چقدر با Estimate فرق دارد؟
بعد Waveهای بعدی دقیقتر میشوند.
Migration را Wave به Wave انجام دهید
برای تعداد زیادی Workload، Big Bang معمولاً ریسک را بالا میبرد.
بهتر است سیستمها در Waveهای منطقی دستهبندی شوند.
مثلاً بر اساس:
- Dependency
- Business Criticality
- Complexity
- Environment
- Migration Strategy
- Application Owner
- یا Technology Stack
Google Cloud در Migration Center پیشنهاد میکند Workloadها بعد از Discovery و Assessment وارد Migration Wave شوند و AWS هم در Portfolio Discovery از ترکیب 7R، Dependency و Complexity برای Wave Planning استفاده میکند.
تغییر کوچکتر یعنی دامنه کوچکتر خطا.
و مهمتر از آن:
هر Wave چیزی به تیم یاد میدهد که میتواند Wave بعدی را بهتر کند.
DNS و Network را دستکم نگیرید
گاهی Application کاملاً سالم منتقل شده، Database هم درست کار میکند، اما Cutover همچنان شکست میخورد.
چرا؟
- DNS
- Routing
- Firewall
- Latency
- VPN
- Load Balancer
- Certificate
- یا Cache
Google Cloud در راهنمای Validation Migration بهطور مشخص توصیه میکند DNS Recordها، TTL، Client-side Cache، Network Connectivity و رفتار Load Balancer قبل از Cutover بررسی شوند.
اگر Hybrid Migration دارید، این موضوع مهمتر هم میشود.
ممکن است Application در Cloud باشد ولی Database هنوز On-premises.
یا Identity هنوز از Active Directory داخلی استفاده کند.
در این حالت Latency و Availability ارتباط بین دو محیط بخشی از معماری Production است، نه یک جزئیات موقت.
تیم عملیات را فراموش نکنید
Migration با روشنشدن آخرین VM تمام نمیشود.
بعد از Go-live کسی باید محیط را اداره کند.
- Monitoring را ببیند.
- Alertها را مدیریت کند.
- Backup را بررسی کند.
- Incident را پاسخ دهد.
- Cost را کنترل کند.
- Patch و Security Update را مدیریت کند.
- و Runbook داشته باشد.
AWS در راهنمای Large Migration تأکید میکند که Cloud Operating Model، Runbookها، Backup/DR، Security و Hypercare باید بخشی از آمادهسازی سازمان باشند.
Cloud ابزار جدید است.
تیم هم باید روش کار با آن را یاد بگیرد.
اگر عملیات همچنان با همان فرآیندهای قدیمی اداره شود، فقط محل سرورها عوض شده است.
بعد از Migration کار اصلی Optimization شروع میشود
یکی از اشتباهات این است که Go-live را پایان پروژه در نظر بگیریم.
بعد از انتقال باید داده واقعی مصرف را ببینید و Resourceها را Optimize کنید.
ممکن است Instance کوچکتر کافی باشد.
Storage Tier تغییر کند.
Auto Scaling فعال شود.
یک Database به Managed Service منتقل شود.
Log Retention اصلاح شود.
Resource بدون استفاده حذف شود.
Reserved Capacity یا مدلهای مشابه برای بعضی Workloadها منطقی شود.
یا معماریای که ابتدا Rehost شده بود، بعدها Replatform شود.
حتی AWS در راهنمای جدید ۲۰۲۶ خود روی رویکرد Migrate → Optimize → Modernize تأکید کرده است.
گاهی سریعتر است ابتدا یک Workload را با تغییر کمتر منتقل کنیم و بعد، وقتی محیط پایدار شد، سراغ Modernization برویم.
Cloud Migration یک Cutover نیست.
یک مسیر است.
Source Environment را خیلی زود خاموش نکنید
بعد از Migration، وسوسه حذف سریع محیط قبلی وجود دارد؛ مخصوصاً چون اجرای همزمان دو محیط هزینه دارد.
اما Source Environment زمانی باید Retire شود که شرایط مشخصی برقرار باشد.
مثلاً:
- تمام Workloadهای موردنظر منتقل شده باشند.
- Data Integrity تأیید شده باشد.
- Backup و DR مقصد تست شده باشند.
- Performance مقصد در محدوده SLA باشد.
- Dependency حلنشدهای به Source وجود نداشته باشد.
- Monitoring ترافیک غیرمنتظرهای به محیط قدیمی نشان ندهد.
- و دوره پایداری موردنظر طی شده باشد.
Google Cloud توصیه میکند معیار Retire کردن Source Environment از قبل مشخص شود.
خاموشکردن سرور قدیمی نباید بر اساس حس خوب بعد از اولین روز بدون خطا انجام شود.
چکلیست قبل از مهاجرت به Cloud
| موضوع | سؤال |
|---|---|
| هدف | چرا این Workload باید به Cloud منتقل شود؟ |
| Inventory | دقیقاً چه Application، Server، Database و Dataای داریم؟ |
| Dependency | این سیستم به چه چیزهایی وابسته است؟ |
| Strategy | Rehost، Replatform، Refactor، Retain یا گزینه دیگری؟ |
| Architecture | مقصد دقیقاً چه شکلی خواهد بود؟ |
| Landing Zone | Identity، Network، Governance و Logging آمادهاند؟ |
| Security | Access، Encryption، Secret و Monitoring مشخصاند؟ |
| Compliance | Data Residency و الزامات قانونی بررسی شدهاند؟ |
| Cost | TCO و هزینه عملیاتی مقصد برآورد شده است؟ |
| Performance | Baseline فعلی داریم؟ |
| Backup | RPO و RTO مشخصاند؟ |
| Pilot | Migration روی یک Workload مناسب تست شده است؟ |
| Rollback | اگر Cutover شکست خورد، مسیر برگشت چیست؟ |
| Operations | چه کسی محیط جدید را مدیریت میکند؟ |
| Optimization | بعد از Go-live چه چیزی اندازهگیری و بهینه میشود؟ |
| Decommission | چه زمانی Source Environment را خاموش میکنیم؟ |
چه زمانی نباید فعلاً به Cloud مهاجرت کنیم؟
Cloud تقریباً برای هر سازمانی ابزارهای مفیدی دارد.
اما این به معنی درستبودن Migration برای هر Workload در همین لحظه نیست.
ممکن است فعلاً مهاجرت منطقی نباشد اگر:
- یک Application به سختافزار خاصی وابسته است.
- Vendor استفاده از نرمافزار را در Cloud پشتیبانی نمیکند.
- Data Residency اجازه انتقال را نمیدهد.
- Latency بسیار پایین به سیستمهای داخل سایت ضروری است.
- هزینه واقعی مقصد نسبت به ارزش Migration توجیه ندارد.
- Application قرار است چند ماه دیگر Retire شود.
- یا تیم هنوز توان عملیاتی اداره محیط Cloud را ندارد.
Retain هم یک Strategy معتبر است.
گاهی تصمیم خوب این نیست که سریعتر Migration کنیم.
این است که بدانیم چه چیزی را هنوز نباید Migration کنیم.
جمعبندی
مهاجرت موفق به فضای ابری از ساخت اولین VM در Cloud شروع نمیشود.
از شناخت محیط فعلی شروع میشود.
باید بدانید چه چیزی دارید، چرا میخواهید منتقلش کنید، چه سیستمهایی به آن وابستهاند و هر Workload با چه Strategyای باید حرکت کند.
بعد Foundation مقصد را میسازید:
Identity.
Network.
Security.
Governance.
Monitoring.
Backup.
و Cost Control.
بعد Pilot میکنید.
Wave به Wave جلو میروید.
برای Cutover مسیر برگشت دارید.
و بعد از Go-live تازه Optimization را شروع میکنید.
Cloud میتواند زیرساخت را منعطفتر و آمادهتر برای رشد کند، اما یک چیز را هنوز خودش انجام نمیدهد:
تصمیمهای معماری را به جای شما نمیگیرد.
ادامه مسیر
مقالات مرتبط
منابع و مطالعه بیشتر
- AWS — 7 Rs of Cloud Migration
- AWS — Assess, Mobilize, Migrate Framework
- Microsoft — Assess Workloads for Cloud Migration
- Microsoft — Azure Landing Zones
- Google Cloud — Assess and Discover Workloads
- Google Cloud — Validate a Migration Plan
- Google Cloud — Migration Planning
- AWS — Preparing an Organization for Large Migration