Technology
›
Enterprise Software & IT
›
Cloud & Platform Engineering
Cloud Infrastructure
Platform decisions with deep integration complexity, organizational change, and long-term data stakes.
Example organizations in this space:
AWS
Microsoft Azure
Google Cloud
HashiCorp
This interactive experience is the shipped product itself — the same application code customers run in production, mounted read-only in your browser over a real sample journey. Not a video, not a mockup: because the demo and the product are one codebase, it can never drift from the real thing.
Inside this journey
-
Pre-Sales
Qualify, diagnose, and validate technical fit before committing to scope and contract.
-
Outcome Discovery
Align on desired outcomes, compliance constraints, stakeholders, and measurable success signals for the cloud migration.
Discovery Questions
Where this migration must deliver value
- Name the primary business outcome this migration must deliver.
- Identify the financial metric you will use to judge success, for example committed spend coverage, monthly run rate, or cost savings.
- Who on your leadership team must sign the migration outcome as acceptable?
- When do you expect to see measurable impact from the initial workload migration?
- Which single metric, if not met after pilot, would cause you to pause or cancel the project?
Where compliance must draw the line
- If a regulator asked for proof of compliance tomorrow, could your team produce it within 5 business days?
- List the certifications, standards, and regulatory regimes this migration must satisfy.
- Who in your organization will lead compliance review and sign off on audit evidence?
- Describe the longest regulatory approval timeline you have faced in the last 24 months and the operational impact it had.
- Which regulatory requirement, if unmet, would stop the migration immediately?
The true stakeholder map
- Anticipate a veto from any stakeholder, who would it be and why?
- List the roles and groups that must approve commercial, security, and legal terms.
- Name the technical owner responsible for cutover and post-migration operations.
- How many people will form the core migration team, including engineering and compliance contacts?
- Identify the role that has final stop/go authority for signing the commercial commitment.
What's already fragile
- Point to the system or process that would cause the largest outage if it failed during migration.
- Describe recent incidents where performance, security, or cost surprised your team and the downstream consequences.
- Estimate the monthly cost volatility you experience today from unmodeled egress, storage tiering, or unreserved capacity.
- Are there third-party dependencies without API or integration support that will require manual migration work?
- What single gap in your current estate would prevent migration within your target window?
The other paths you are weighing
- If you kept your current vendor, what condition would have to be true for you to stay?
- Select the alternatives you have evaluated or are currently evaluating.
- Note the incumbent systems or services you expect to replace with this migration.
- Provide details on whether anyone internally proposed an internal build option and the resource estimate they provided.
- What would a competing option need to prove to keep your business from switching now?
How you will measure success
- Assume the pilot meets the required security controls but exceeds cost targets by 20 percent; would you greenlight a full migration?
- Provide the technical and commercial acceptance criteria that must be satisfied at cutover.
- Assign the role responsible for signing the acceptance certificate and confirming production readiness.
- How will you measure cost adherence against the committed spend on a monthly cadence?
- Imagine the pilot meets technical criteria but the first month of production shows a 15 percent increase in run-rate, what decision will you make?
Can your team run with this?
- Pinpoint the critical internal capability currently missing that would stop the project at handover.
- Do you have named system owners and SREs assigned for migration and initial operations?
- Is your data located in jurisdictions that meet your target residency requirements?
- Detail the integration endpoints that must be available before cutover and the owning teams.
- Estimate the number of full time equivalents you can commit to migration support for the first 90 days.
- Is there any legal or procurement approval that, if not granted within your target window, would cancel the migration?
Early signals and next steps
- Assume the pilot proves the metrics you require, what would stop you from signing a commitment in the same month?
- Select the artifacts that would help your team accelerate decision making.
- Share the individuals or roles who should attend a technical working session next week to accelerate design and acceptance criteria.
- When is your target date to start a pilot?
- Explain how you will track pilot success and who will receive regular reports.
- Given an architecture review, security summary, and validated cost model within two weeks, would you be prepared to enter commercial talks?
-
Technical Evaluation
Validate the platform against the buyer's security, compliance, and performance acceptance criteria via architecture review and targeted tests.
- decision_readiness
- current_state
- desired_state
- success_criteria
- gaps
- stakeholders
- decision_readiness
- current_state
- stakeholders
- gaps
- desired_state
- success_criteria
- success_criteria
- desired_state
- stakeholders
- gaps
- current_state
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
-
-
Solution Scope
Define solution boundaries, modules, compliance controls, responsibilities, and measurable acceptance criteria for the migration and operation.
Scope Configuration
- Provision certified data center regions
- Provision isolated network segments with enforced encryption
- Provision compute instances with reserved-capacity pricing
- Migrate virtual machines and attached storage
- Migrate block and object storage with tiering policies
- Provision managed databases and migrate data
- Deploy container orchestration clusters with compliance baselines
- Provision managed AI model hosting and inference endpoints
- Configure IAM, access boundaries, and role-based policies
- Enable audit logging and compliant log retention stores
- Configure customer-managed encryption keys and rotation
- Enable Terraform provider and Pulumi SDK with example modules
- Configure transparent egress billing and usage alerts
- Deliver compliance evidence package and certification artifacts
Scope Questions
Provision certified data center regions
- Which certified region(s) must host regulated datasets (for example FedRAMP Moderate, HITRUST, PCI DSS scoped workloads)?
- List the regulatory constraints that mandate region selection for any workload (for example data residency, cross-border transfer restrictions, regulator-approved subprocessors).
- How much persistent storage and compute (estimate in TB and vCPU) will you place in each certified region for the initial migration wave?
- Who in your compliance or legal team will sign region residency attestations and be listed as the regulator contact for region approvals?
- Are any workloads subject to a minimum physical separation (for example entirely on-premises enclave or dedicated tenancy) rather than logical separation?
Provision isolated network segments with enforced encryption
- Which workloads require isolated network segments with enforced in-transit encryption between components (for example PHI flows, cardholder data environments)?
- Provide the network addressing needs for each segment: CIDR ranges, expected peak concurrent connections, and required private endpoint counts.
- Specify the minimum TLS or IPsec standards you require within segments (for example TLS 1.2 minimum, perfect forward secrecy requirement).
- Which network controls must be enforced at segment boundaries (for example egress ACLs, IDS/IPS signatures, DDoS mitigation for public endpoints)?
- Who will own network segmentation changes on your side and provide signed change approvals for production cutover?
Provision compute instances with reserved-capacity pricing
- How many instance families and sizes do you plan to reserve initially (for example general purpose 4 vCPU x 16 GiB, memory-optimized profiles)?
- Estimate the committed-spend ramp you can accept for reserved capacity in year one (for example steady-state minimum annual commitment or phased ramp to minimum).
- What sustained-utilization threshold should trigger reserved instance sizing (for example 70% average CPU over 30 days)?
- Which workloads require CPU or memory pinning, dedicated tenancy, or special licensing support (for example third-party enterprise database licenses)?
- Who will own monthly usage reviews and reserved-capacity adjustments on your team?
Migrate virtual machines and attached storage
- How many virtual machines and total attached disk capacity (in TB) are in the migration wave you expect in scope?
- Which hypervisor formats or VM images must be supported from your current estate (for example VMDK exports, VMX, or raw disk images)?
- What is your maximum acceptable recovery point objective and recovery time objective per VM during cutover (for example RPO 15 minutes, RTO 2 hours)?
- What acceptance criteria will confirm the migration of virtual machines and attached storage is complete (for example 99.9% service process health, successful boot in production VPC, and automated functional smoke tests passing)?
- Identify any VM-level licensing or agent requirements that must be preserved during migration (for example antivirus, configuration management agents).
Migrate block and object storage with tiering policies
- Which data sets will move to object storage versus block storage (for example backups, image repositories, transactional volumes)?
- Specify tiering policies required for each dataset (for example hot <30 days, cool 30-365 days, archive >365 days) and expected lifecycle rules.
- How much egress per month do you estimate from object tiers during normal operation and during initial bulk migration (in TB)?
- Which data integrity checks do you require post-migration for objects and blocks (for example checksums, object count parity, metadata verification)?
- Who will approve deletion or tiering transitions that are subject to regulatory retention (for example records retention officer)?
Provision managed databases and migrate data
- Which database workloads are in scope (for example OLTP PostgreSQL, OLAP data warehouse, Oracle-like schemas, MySQL replicas)?
- Estimate total data size and peak transaction rate for each database in the wave (for example 2 TB, 5k TPS).
- What migration approach do you prefer for each database (for example lift-and-shift snapshot, logical replication, change-data-capture cutover)?
- What acceptance criteria will validate data integrity for database migrations (for example row-count parity, checksum match >= 99.999%, and application-level transaction validation)?
- Are there special encryption, key access, or Bring Your Own License (BYOL) requirements for any database engines?
Deploy container orchestration clusters with compliance baselines
- Which workloads will run in container clusters subject to compliance baselines (for example workloads handling PHI, financial transaction processors)?
- Specify baseline controls required for clusters (for example CIS Kubernetes benchmark profile, network policy enforcement, pod security policies).
- How many clusters and what availability topology do you require (for example 3 AZ spread, multi-region failover)?
- Which container registry and image signing policies must be enforced at admission (for example SBOM required, signed images only)?
- Who will own runtime policy exceptions and approve cluster baseline exceptions?
Provision managed AI model hosting and inference endpoints
- Which model types and inference profiles are in scope (for example transformer-based models for PHI extraction, small models for telemetry analysis)?
- What inference latency and throughput SLOs must be met for production endpoints (for example p95 < 200 ms, 1000 requests per minute)?
- Which data handling restrictions apply to model input and output (for example no PHI persisted, audit trail of inference requests, model explainability artifacts)?
- Do you require customer-managed encryption of model artifacts and weights at rest?
- Who will be responsible for model retraining schedules and validation sign-off in your organization?
Configure IAM, access boundaries, and role-based policies
- How many distinct roles and least-privilege boundaries must be created initially (for example admin, security auditor, service account, operator)?
- Which users or service principals require cross-account or cross-tenant access for migration tasks (for example backup service account, monitoring service principal)?
- Specify required multi-factor authentication and session duration policies for privileged roles (for example MFA mandatory, session timeout 1 hour).
- Do you require just-in-time privileged access or ephemeral credentials for operator actions during cutover?
- Which auditable access reports or access certification cycles must be exported for your compliance team (for example quarterly access certification exports)?
Enable audit logging and compliant log retention stores
- Which log types must be ingested and retained for compliance (for example access logs, admin API calls, DB slow query logs, audit trail of PHI access)?
- What retention periods are mandated by your regulators for each log type (for example 1 year, 3 years, 7 years)?
- Which log integrity or tamper-evidence controls do you require (for example WORM storage, signed digests, time-stamped append-only stores)?
- How will security operations validate log ingestion during migration (for example synthetic events, baseline event rate comparisons)?
- Who is responsible for responding to retained audit findings and providing evidence to auditors?
Configure customer-managed encryption keys and rotation
- Do you require customer-managed keys (CMK) in a dedicated key management service for any regulated dataset?
- Specify your required key rotation frequency and any escrow or split-key arrangements mandated by your regulator.
- Which key usage restrictions or policies must be enforced (for example key usage limited to a single region, key use audited per operation)?
- Who will be the authorized key administrator and who is the sign-off authority for key revocation?
- Are there backup and key-recovery SLAs you require in scope (for example escrow with third-party custodian)?
Enable Terraform provider and Pulumi SDK with example modules
- Which IaC workflows do your engineers currently use and expect example modules for (for example Terraform v1.x, Pulumi in TypeScript, CI/CD pipelines)?
- What catalog of example modules do you expect out of the box (for example VPC + subnet, managed DB with backup, container cluster with baseline policies)?
- Do you require signed example modules and provenance (for example module signatures and module-level SBOMs)?
- Who will own internal IaC review and acceptance for shipped example modules (for example platform engineering lead)?
- Would you like training sessions or runbooks for onboarding your engineers to the provider Terraform and Pulumi modules?
-
Mutual Commit
Finalize commercial and legal terms including committed-spend, SLAs, certification attachments, and mutual obligations.
Agreement Modules
- Subscription Agreement
- Order Form & Committed-Spend Schedule
- Service Level Agreement (SLA)
- Data Processing Agreement (DPA)
- Regulatory & Certification Addendum
- Security & Incident Response Addendum
- Onboarding & Migration Assistance Addendum
- Termination, Data Return & Egress Addendum
- Audit & Compliance Review Rights
-
Deployment
Lock readiness facts, configuration, and execute migration with compliance sign-offs.
-
Pre-Deployment Readiness
Confirm concrete readiness facts — data residency, access, named owners, rollback plans, and regulatory preconditions required to execute.
Pre-Deployment Questions
Environment and access
- Are the target environments (staging, pre‑prod, production) provisioned and reachable from the platform network? If not, state the earliest date access will be available (so we can schedule pre-cutover tests).
- For external integration categories the rollout touches, select all categories that have a production endpoint and a named point of contact.
Data and configuration
- Are data residency and data classification requirements for the migrating datasets confirmed? If yes, list the required region(s) and dataset owner(s) (region names and owner names only).
- Has the scope decision been made for which datasets/systems will migrate vs remain on‑premise, and is an owner assigned for the source-of-truth mapping?
People and ownership
- Provide the named owner (name and role) for each deployment stream: network, security/compliance, application, data migration, and rollback (one line per stream).
- Are the buyer approvers required for compliance and production sign‑off identified and available for scheduled reviews (for example: CISO, compliance officer, data protection officer)?
Timing and constraints
- List any blackout windows, regulatory audit periods, or business‑critical dates when changes are prohibited (date ranges only).
- Which pre‑execution regulatory or contractual conditions remain outstanding? Select all that apply (these must be cleared before production cutover).
- Is a tested rollback plan defined, approved, and assigned an owner? If yes, provide the owner's name and approval date; if no, provide the target completion date (so we know clear go/no‑go criteria).
- Will the buyer require monthly consumption tracking against committed spend during the rollout, and who will own monthly cost/usage reviews (name and role)?
-
Configuration Details
Capture exact deployment parameters the team will use — network topology, encryption keys, reserved capacity, egress modelling, and integration endpoints.
Configuration Details
Environments & Endpoints
- Primary deployment environment name (single token used by the build; e.g., prod-us-east-1) — Default: prod
- Primary deployment region (select the certified region footprint the build will target) — Default: US - single region
- Public API hostname or management endpoint for this environment (format: https://your-hostname.example.com) — this value is written to DNS records and TLS provisioning
Network & Connectivity
- Network topology model for this environment (consumed by network provisioning)
- Primary CIDR block the platform should provision for this environment (format: CIDR e.g. 10.0.0.0/16) — Default: 10.0.0.0/16
Encryption & Key Management
- Key management model for data-at-rest encryption (select one) — Default: Platform-managed keys
- If using a customer-managed key, provide the key identifier (key name / ID / ARN as applicable). Do NOT paste key material—this is an identifier only; leave blank if not applicable.
Capacity, Integrations & Operational Limits
- Reserved compute commitment to provision (vCPU count guaranteed monthly for pricing and capacity; numeric) — Default: 0
- Expected average monthly egress (GB) for cost/egress modeling (numeric) — Default: 1000
- Identity provider type for user authentication (select one) — if selecting SAML or OIDC, you will provide the IdP metadata URL in the connector settings page
Audit, Compliance & Runbook Inputs
- Audit log retention period in days (numeric) — Default: 365
- Log export endpoint (archive location URL for audit exports; format: https://...) — used by log shipping and retention jobs
- Will a hard-copy or electronic penetration-test report be provided during go-live validation? (Yes = report provided; No = not provided)
-
Migration Execution
Execute the rollout with a scheduled plan, owners, compliance checkpoints, and ongoing cost/usage tracking against the committed spend.
-
Go-Live Validation
Formal acceptance checklist confirming penetration test results, audit logging, incident response SLAs, and compliance sign-offs before production cutover.
Checklist items
- Receive final penetration test report with remediation verification
- Confirm audit logging and immutable log storage are enabled for production systems
- Obtain incident response SLA and escalation/contact matrix signed by both parties
- Execute incident response tabletop or simulated test and record outcomes
- Validate RBAC, administrative access provisioning, and MFA for production admin accounts
- Verify backup/restore and rollback plan with a successful restore test
- Confirm control mapping and obtain written compliance sign-off
- Upload and index all go-live evidence artifacts to the shared repository
- Obtain explicit production cutover authorization from the designated approver (and from each named site owner where multiple sites are in scope)
- Confirm monitoring, alerting, and committed-spend dashboards are configured and acknowledged
-
-
Success
Monitor outcomes, review consumption vs committed spend, and track issues, enhancements, and audit evidence in a shared channel.
Success Reviews
- Go-live health check (weeks 1-4)
- First measurement, initial outcomes (weeks 4-10)
- 90-day realization review and incumbent wind-down (around day 90)
- Ongoing monthly consumption and compliance sync (recurring monthly)
- Quarterly operational review, long-term realization (recurring quarterly)
Issues & Enhancements
- Update the usage vs commitment dashboard and circulate an annotated variance explanation each month.
- Agree the prioritized focus areas for the next quarter to reduce cost variance and close compliance items.
- Publish the 90-day realization report with metric trends, remediation status, and incumbent decommission confirmation.
- Open any required change requests to adjust reserved capacity or cost allocations based on observed usage.
- Schedule targeted remediation sprints for outstanding compliance findings with completion dates.
- Consumption and spend report
- Keep monthly consumption within tolerances against the committed spend and address any emerging cost drivers quickly.
- Ensure compliance remediation items are progressing to resolution within agreed SLA windows.
- Reduce the number of unresolved high-severity operational issues month over month.
- Reconfirm success criteria and owners
- Create short-run remediation tickets for any new high-severity compliance findings.
- If variance persists, propose a specific reserved capacity or configuration change for approval.
- Executive summary of realization trends
- Confirm multi-quarter trajectory for consumption and compliance and decide on any required structural adjustments.
- Ensure all required audit evidence is archived in the shared channel and accessible for upcoming reviews.
- Close or re-scope long-running operational blockers with clear timelines and acceptance criteria.
- Publish the quarterly realization packet with trend charts, audit evidence index, and open issue register.
- Propose any reserved capacity or configuration changes needed to reduce recurring cost variance.
- Schedule focused remediation work for remaining high-impact compliance findings with target close dates.
- Deployment is confirmed stable for initial operations and no unresolved showstopper defects remain.
- Named owners are recorded for all open issues and remediation target dates are agreed.
- The team agrees the timeline for the first measurement meeting and the data sources to be used.
- Publish a go-live health summary that lists open issues, owners, and target remediation dates.
- Confirm and share the data sources and queries that will supply the first measurement meeting.
- Agree a prioritized remediation plan with target dates to address the primary causes of cost or compliance variance.
- Confirm the data and evidence set required for the 90-day realization review.
- Present first measurement data
- Determine whether monthly consumption and egress cost trends are headed toward the Solution Scope targets and document gaps.
- Deliver a cost-variance detailed review report that breaks down egress, storage tiering, and reserved capacity impact.
- Publish a compliance evidence bundle including audit logs and penetration test status for the 90-day review.
- Create a tracker for remediation tasks with owners and target completion dates.
- Restate where targets are recorded
- Establish a clear status of realization against Solution Scope targets and a timebound plan to close remaining gaps.
- Confirm incumbent system is either decommissioned or formally retained read-only with archived data and closed fallback habits.
- Present 90-day outcome data vs Solution Scope targets
- Compliance evidence and audit readiness
- Deployment and migration validation
- Egress and storage cost variance review
- Compliance and security evidence snapshot
- Compliance items and incident response SLA review
- Early adoption and health signals
- Remediation status and closure plan
- Operational risk register and long-running blockers
- Root-cause diagnosis for gaps
- Incumbent system wind-down checkpoint
- Blockers and open issues with owners
- Agree corrective actions and timelines
- Capacity, reserved instance, and cost optimization review
- Open issues and enhancement backlog
- Agree immediate remediation actions
- Confirm readiness for the 90-day realization review
- Agree next 90-day priorities