Opening the conversation: the migration trigger and scope

• Tell me about the migration trigger that's driving your timeline, for example a data center lease end, a cost reduction mandate, or an application end-of-life notice.
• When is your target cutover for the first migration wave? Options: Within 4 weeks, 4-8 weeks, 8-12 weeks, 3-6 months, 6-12 months, 12+ months
• How many production applications and databases are in your full portfolio today, and how many of those are considered business critical?
• Which of those systems run customer-facing workloads versus internal business functions, select all that apply. Options: Customer-facing web/mobile, B2B APIs, Internal ERP/Finance, Internal HR/Payroll, Analytics/data warehouses, Other
• Who on your team will own the go/no-go decision at the program level, and who are the alternates? Options: CIO/CTO, VP Infrastructure, Cloud Program Director, Head of Applications, Procurement lead, Other

Where the current setup breaks, and why it matters

• If undocumented dependencies exist, describe the failures you'd expect to see within 30 days of a wave cutover.
• Describe a recent migration or infrastructure change that caused unexpected production impact and explain why it was missed in advance.
• How often do patching, network changes, or configuration updates create application outages today? Options: Almost every change causes issues, Occasionally causes issues, Rarely causes issues, Never in recent history
• Estimate the typical monthly variance between forecasted infrastructure spend and actual billed spend, as a percentage or absolute value. Options: Under 5%, 5-15%, 15-30%, 30%+, Prefer to enter absolute value
• What single technical or organizational failure would make you stop the migration entirely?

Hidden connections that will break the plan unless we surface them

• Walk me through how you currently discover and document application dependencies, including the artifacts produced and who updates them.
• Which integration endpoints, middleware components, or legacy proxies are required for your top 20 most critical applications? Options: API gateways, Message buses/queues, File shares/FTP, Legacy brokers, Direct DB links, Other
• Who owns the APIs or integration contracts that a migration must preserve, and are their SLAs or support windows documented? Options: Application team, Platform/Integration team, Third-party vendor, No clear owner
• Do you have network diagrams and a configuration management record that link applications to IP ranges, VLANs, and firewall rules? Options: Yes, up to date, Yes, but out of date, Partial diagrams exist, No
• Typically, how many business days does it take for your teams to provide credentials or access to an external migration engineer when requested? Options: Same day, 1-3 business days, 4-7 business days, More than 7 business days

What's most at risk financially and operationally

• What's the gap between your current data center run rate and the cloud cost estimate you would accept as the target? Options: Cloud target is lower by >20%, Cloud target is lower by 5-20%, Roughly equal, Cloud target is higher by 5-20%, Cloud target is higher by >20%
• Identify the workloads that drive the majority of your monthly spend and note whether they are stateful (databases), stateless compute, or large storage objects. Options: Stateful databases, Stateful storage-heavy apps, Stateless compute, Big data/analytics, Other
• If cost estimates exceed your target by 20 percent, what authority or budget tradeoffs can be approved to proceed? Options: Approve budget increase, Reduce scope/wave size, Apply cost optimization post-migration, Delay migration, Other
• Assuming the pilot confirms dependency mapping accuracy, cost estimates, and runbooks, describe what would still stop you from signing a program SOW within two weeks.
• Rate your confidence in the fidelity of your current cost tagging and billing data, where 1 is not confident and 5 is fully confident. Options: 1, 2, 3, 4, 5

Roadblocks that slow or pause progress

• Name the internal approval that most often delays infrastructure changes or access for migrations. Options: Security approval, Network change window, Application owner sign-off, Finance budget approval, Legal/compliance sign-off, Other
• Do you have contractual no-migration zones, vendor support restrictions, or licensing caveats that could block moving certain workloads? Options: Yes, multiple, Yes, a few, None known, Unsure
• Tell me about recent audit findings or compliance notes that would require remediation before we schedule a wave cutover.
• What single regulatory or contractual constraint would pause your migration program immediately if it remained unresolved?
• Estimate the headcount shortfall, in full time equivalents, for teams that lack capacity to support a migration wave. Options: 0 FTE, 0.5-2 FTE, 2-5 FTE, 5+ FTE

The other paths you're weighing

• Imagine you stayed with your current vendor or built the migration internally, describe what would need to change for you to cancel a partner-led program.
• List the alternatives you are actively evaluating today, categorized as incumbent vendor, consultant/integrator, or internal delivery. Options: Incumbent vendor, System integrator/consultant, Internal team build, Cloud provider professional services, Other
• Identify the internal proposal owners who have advocated for an all-internal approach and summarize their main rationale.
• List the measurable outcomes your current approach would need to deliver to justify staying the course rather than engaging a partner.
• Select all of the following alternatives you have already engaged with or requested proposals from. Options: Incumbent vendor proposal, External consultant proposal, Internal capability plan, Proof of concept with in-house team, No alternatives engaged yet

Operational readiness and constraints we must surface now

• Assume cloud accounts, IAM roles, and network setups must be ready before a wave, what currently blocks being ready for your first wave?
• For each third-party system that must remain live during migration, indicate whether APIs are available, who owns them, and whether documentation exists. Options: APIs available and documented, APIs available but undocumented, No API, manual integration required, Not applicable
• Specify the teams that must dedicate an engineer or SME per wave and indicate estimated weekly hours they can commit. Options: Application owners, Network/Security, Database administrators, Middleware/Integration, Platform/DevOps, Other
• Is your data classified and accessible for extraction, including personal data restrictions or residency rules that could delay migration? Options: Classified and accessible, Classified with restrictions, Not classified but restricted by residency, Unclassified and accessible
• Explain whether a temporary control exception can be granted to proceed when a required compliance approval is missing for a wave, or whether that would cause a delay. Options: Can grant temporary exception, Cannot grant exception, must delay, Decision depends on scope

Pilot success criteria and timeline that move decisions

• Assuming the pilot meets its goals, describe the evidence and approvals that would convince your leadership to commit to a full program within 30 days.
• Provide the KPIs you will use to accept the pilot, for example cutover time, rollback success, cost delta, and post-migration performance. Options: Cutover time, Rollback success, Cost delta vs forecast, Application performance (latency/throughput), Error rate incidents, Other
• State the acceptance thresholds for cost, uptime, and data integrity that you will require for a successful pilot.
• Given a pilot that validates dependency mapping but misses cost targets, which outcome would you prefer: adjust strategy and continue, pause to redesign, or stop the program? Options: Adjust strategy and continue, Pause to redesign, Stop program
• When do you need the pilot completed to meet your broader migration deadline? Options: Within 2 weeks, Within 1 month, 1-3 months, 3-6 months, 6+ months

Decision drivers and next steps that shorten the timeline

• Should the pilot prove the numbers, what single outstanding issue would prevent you from signing a program agreement that same week?
• Provide the names, roles, and typical review cadence for procurement and legal stakeholders who must approve commercial terms.
• Please prioritize the documents or artifacts that would accelerate contracting, ranking items you expect to see first. Options: Statement of Work, Security and compliance questionnaires, Runbook and cutover plan, Cost model and TCO analysis, Pilot report and acceptance evidence
• Name the single meeting, escalation, or decision that would move the program to yes this quarter.
• Indicate your preferred channels for sharing pilot artifacts, runbook drafts, and access credentials, and list who on your side should have access. Options: Secure portal/workspace, Encrypted email, Shared drive with restricted access, Platform workspace, Other

• Solution Experience: Migration Strategies and Cost Modeling

• Confirm the current state and its cost to your team
• You confirm the demonstrated migration decisions for the sampled workloads eliminate the failure modes you described.
• Prepare a wave-specific migration decision report for the three sampled workloads, including chosen strategy, high-level runbook, and estimated effort.
• You accept that the dependency mapping output reflects the actual integrations for the pilot workload.
• Validate consequence with portfolio metrics
• Deliver dependency mapping export and an annotated topology diagram for the pilot workload before pilot kickoff.
• You agree the cost model projections are directionally accurate and identify the remaining data points required to finalize estimates.
• Provide inventory exports and contact details for the two sample workload owners for the scenario walkthroughs.
• Walk through migration strategy decisions for sample workloads
• You agree on pilot scope, acceptance criteria, and the next evidence required to move to Pilot Migration & Validation.
• Prove dependency mapping with a topology walkthrough
• Share recent data center cost statements and any target budget constraints used to validate cost model assumptions.
• Confirm pilot acceptance criteria and a provisional pilot window so the migration team can schedule resources.
• Show cost model outputs for the same scenarios
• Validate the fit with your stated priorities
• Agree pilot scope, acceptance criteria, and next evidence

• Solution Experience: Migration Strategies and Cost Modeling
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• Provision cloud landing zone and account baseline
• Run automated dependency mapping and topology export
• Execute pilot workload migration runbook
• Rehost application workloads (lift-and-shift)
• Replatform workloads to managed cloud services
• Refactor application to cloud-native architecture
• Migrate relational and NoSQL databases with cutover
• Migrate file shares and object storage with sync
• Implement identity and access controls (IAM)
• Configure security and compliance baselines and logging
• Right-size compute and implement cost controls
• Execute migration factory wave for bulk migrations
• Decommission on-premises resources and connectivity cutover
• Deploy monitoring, performance tuning, and SLO verification

Provision cloud landing zone and account baseline

• Which cloud account IDs or names will be used for the management and shared services accounts?
• Who in your organization approves new account creation and will sign the landing zone account provisioning change request?
• Do you have an existing account baseline policy document (for example: approved service control policies, tagging, and guardrails)? Options: Yes, No
• How many workload/enclave accounts do you require in the baseline (separate dev/test/prod counts)? Options: 1-2, 3-5, 6-10, More than 10
• Specify the required network CIDR allocations or VPC/subnet partitioning for each account (provide CIDR per account)
• Provide your required baseline logging and retention policy for account-level logs (SIEM log types and retention in days) Options: 30 days, 90 days, 365 days, Other

Run automated dependency mapping and topology export

• Which environments and hostnames should the dependency mapper scan (example: onprem-app01.local, datacenter-subnet-42)?
• Who will provide access for agent-based discovery or network flow collection (include SSH user, service account, or packet-mirror permissions)?
• Do you require database-level dependency discovery (stored procedure callers, cross-schema links) in addition to network flows? Options: Yes, No
• How many application topologies do you expect exported as topology.json or topology CSVs for wave planning? Options: 1-10, 11-50, 51-200, 200+
• Identify any network segments or IP ranges that must be excluded from automated scanning (for example: management VLAN 10.255.0.0/16)
• Provide the minimum dependency coverage threshold you need for a topology export to be considered usable (e.g., 95% of known integration endpoints) Options: 70%, 80%, 90%, 95%+

Execute pilot workload migration runbook

• Which non-production workload will be used as the pilot (application name, environment, VM/instance IDs, database name)?
• Who is the application owner responsible for pilot cutover and rollback sign-off (name and email)?
• Provide the runbook version and repository path that the migration team should execute for the pilot (runbook filename and version tag)
• When is the proposed pilot migration window (date and start/end times in your local timezone) and what is the DNS TTL to use for cutover?
• What performance and functional acceptance criteria will confirm the pilot migration is successful (for example: p95 response time < 300ms, end-to-end transaction success rate > 99%, synthetic test IDs pass)?
• Specify required validation artifacts after pilot (dependency map post-cutover export, transaction trace sample, and cost estimate report)

Rehost application workloads (lift-and-shift)

• Which application VMs or physical hosts are candidates for lift-and-shift in the first wave (list hostnames and roles)?
• Who will own OS-level hardening and patch validation after rehost in your team?
• Do you require agent-based replication or image conversion (for example: block-level replication with agent vX.Y) for rehosted VMs? Options: Agent-based replication, Image export/import, Cold restore from backup, Other
• How long is the permitted cutover outage per host or cluster (maximum minutes or hours allowed for DNS and data sync) for lift-and-shift? Options: No downtime required, Up to 30 minutes, 30-120 minutes, More than 2 hours
• Provide the sizing target for the rehosted instance (vCPU, RAM, disk profile) and whether you expect initial right-sizing post-migration
• Identify any out-of-scope items for rehosting (for example: OS licensing remediation, application refactor, vendor upgrade tasks)

Replatform workloads to managed cloud services

• Which workloads do you want replatformed to managed services (list app name, current runtime and target managed service category)
• Who approves using managed services that may change operational responsibility (for example move from self-managed DB to managed DB-as-a-service)?
• Do you have constraints on managed service regions or data residency that affect replatform choices? Options: Yes, No
• Specify required migration artifacts for replatforming (schema migration scripts, connection-string templates, and integration endpoint certificates)
• How should stateful components be migrated to the managed service (online replication with cutover, export/import, or hybrid proxy)? Options: Online replication, Export/import, Proxy-based cutover, Other
• Indicate any licensing, SLA, or support approvals needed before moving to the target managed service

Refactor application to cloud-native architecture

• Which applications are in scope for refactor to cloud-native (include repo links, current framework, and major modules)?
• Who will provide application-level acceptance tests for the refactor effort (test owner and location of test suite)?
• Describe required refactor deliverables (container image, CI/CD pipeline config, infrastructure-as-code templates)
• Do you require backward-compatible releases during refactor (strangler pattern) or a big-bang cutover for each service? Options: Strangler pattern (incremental), Big-bang cutover, Hybrid
• Provide performance targets for refactored services (for example: p95 API latency < 200ms and 99.9% availability during business hours)
• List any developer tooling or language runtime versions that must be preserved or upgraded as part of the refactor

Migrate relational and NoSQL databases with cutover

• Which databases (name, engine, version, size, primary host) are planned for the first database cutover?
• Who is responsible for schema change approval and data reconciliation post-cutover (include DBA contact)?
• Do you require logical replication, physical replication, or backup/restore for each listed database? Options: Logical replication, Physical replication, Backup/restore, Other
• How much replication lag is acceptable during cutover in seconds or minutes (RPO target)? Options: Near-zero (< 5s), Under 1 minute, 1-15 minutes, 15+ minutes
• What acceptance criteria will confirm a successful database cutover (for example: checksum parity, zero missing transactions, post-cutover application smoke tests pass)?
• Specify required runbook steps for rollback for each database type (script path, snapshot tag format, and restore verification script)

Migrate file shares and object storage with sync

• Which file shares or object prefixes are in scope (provide UNC paths or bucket prefixes and approximate total GB/TB)?
• Who owns the file-share metadata and will validate post-sync file integrity (name and email)?
• Do you require preservation of ACLs and NTFS permissions during migration for SMB/NFS shares? Options: Preserve ACLs/NTFS, Map to cloud IAM, Drop permissions and reapply manually
• How will you validate object parity after sync (checksum, file counts, sample file open tests)? Options: Checksum, File count, Sample open, Other
• Provide the acceptable bandwidth window and sync throttling policy (max throughput in MB/s or time-of-day windows)
• Indicate any archival or lifecycle rules that must be applied post-migration (for example: lifecycle to IA after 30 days)

Implement identity and access controls (IAM)

• Which IAM roles or groups must be created or mapped during the migration (provide role names and intended permissions)
• Who will approve role-to-person mappings and provide least-privilege access attestations?
• Do you require integration with your existing identity provider for single sign-on and provisioning (include protocol like SAML or OIDC)? Options: SAML, OIDC, LDAP/AD Federation, None
• Specify any privileged access workflows required (just-in-time elevation, approval ticket ID format, and max elevation time)
• Have you defined service account naming and rotation policies we must implement during IAM onboarding? Options: Yes, No
• List any compliance roles requiring separation of duties that must be enforced (for example: change approver separate from deployment executor)

Configure security and compliance baselines and logging

• Which compliance frameworks apply to these workloads (for example: PCI-DSS, HIPAA, GDPR) and which controls must be demonstrated?
• Who will provide the control objectives and evidence owner for each required compliance control?
• Do you require centralized log ingestion to a SIEM with specific event types and retention (list event classes and retention days)? Options: Audit logs only, Audit + Application logs, Full packet/flow capture, Custom
• Specify required encryption standards for data at rest and in transit (for example: AES-256 at rest and TLS 1.2+ in transit)
• Are there regulatory reporting templates or evidence formats we must produce (for example: attestation CSV, control testing workbook)? Options: Yes, No
• Provide the desired SIEM alert thresholds and escalation path for critical events (alert severity mapping and pager/SLACK channel)

• success_criteria
• stakeholders
• gaps
• current_state
• decision_readiness
• desired_state
• decision_readiness
• desired_state
• success_criteria
• stakeholders
• gaps
• current_state
• stakeholders
• decision_readiness
• current_state
• desired_state
• success_criteria
• gaps
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Commercial Order Summary
• Security & Compliance Addendum
• Industry-Specific Compliance Addendum (conditional)
• Data Processing Agreement (DPA)
• Data Access & Authorization
• Acceptance Criteria & Go/No-Go Gate
• Service Level Agreement (SLA) for Migration Support
• Change Order Agreement

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate and Formal Ratification (around day 90)
• Lessons Learned and Enhancement Backlog (2 weeks after acceptance)
• Quarterly Outcomes Review (ongoing quarterly)

• Publish the prioritized enhancement and defect backlog with acceptance criteria for each item.
• Confirm the incumbent system wind-down plan status including data archive or migration completion and closure of fallback operations.
• Agree remediation items for any failed or conditional criteria with clear resolution dates and a verification checkpoint.
• Publish the signed acceptance record and the per-criterion pass/fail table.
• Initiate legacy system decommission tasks or retention steps and publish the archive verification report.
• Create a remediation plan with milestones for any failed acceptance items and schedule the final verification meeting.
• Structured lessons learned
• Produce a prioritized backlog of enhancement requests and defects derived from the migration and hypercare period.
• Agree a regular tracking cadence for backlog items and a verification method for completed enhancements.
• Re-confirm success criteria and owners
• Schedule the first backlog grooming session for items targeted in the next quarter.
• Circulate a lessons learned summary document to the broader program team.
• Quarterly cost realization review
• Confirm whether quarterly cloud spend aligns with the Solution Scope targets or identify sustained variance requiring a course correction.
• Ensure critical application availability remains at or above the agreed target and that any regressions have remediation plans.
• Maintain a single prioritized backlog and agree the top items to be delivered in the next quarter.
• Publish the quarterly cost and availability report with identified variance drivers and recommended actions.
• Update the enhancement backlog status and mark items planned for next-quarter delivery.
• Schedule any follow-up detailed review sessions for unresolved high-severity issues.
• Confirm that cutover steps completed and there are no unresolved critical outages preventing business operations.
• Establish the top five open issues with owners and target resolution dates to drive hypercare work.
• Publish go-live validation checklist and current issue register with owners and dates.
• Produce an immediate mitigation or rollback plan for any critical issue identified.
• Collect and circulate the runbook execution logs for the pilot workloads for audit.
• Present first outcome data
• Establish whether monthly cloud spend is within the tolerance band of the targets recorded in Solution Scope and document variance drivers if not.
• Agree a prioritized remediation plan to bring critical application availability to the target percent within the agreed timeline to the acceptance gate.
• Produce an updated cost projection that reflects measured usage for review at the Acceptance Gate.
• Publish a variance analysis report for monthly cloud spend showing drivers and recommended corrections.
• Create a prioritized remediation tracker for availability gaps with target dates to close before the Acceptance Gate.
• Deliver an updated cost projection and sizing worksheet for acceptance review.
• Restate acceptance criteria and pass/fail thresholds
• Produce a documented acceptance decision with pass/fail result per acceptance criterion recorded in Solution Scope and a named signatory for managed engagements.
• Performance and availability trends
• Deployment and migration validation
• Present outcome data against each criterion
• Issue triage and defect capture
• Root-cause analysis for gaps
• Prioritize enhancements and schedule follow-up
• Early adoption and usage signals
• Enhancement and issue status
• Document pass/fail and capture signatory decision
• Agree corrective actions and timelines
• Confirm ongoing reporting and owner for backlog
• Blockers, incidents, and open issues
• Confirm timeline to Acceptance Gate
• Agree next-quarter operational actions
• Incumbent system wind-down confirmation
• Agree immediate remediation actions
• Update migration cost and sizing model
• Agree remediation items and closure timeline