Generate Billing

Known limitations: Partial IaC discovery (mixed Terraform + billing-only services) is not yet supported. Confidence scoring per service based on billing SKU specificity is not yet implemented.

Overview

This file produces a complexity-scaled migration plan with wider timelines and lower confidence thresholds than the infrastructure path. Billing-only data provides service-level spend but lacks configuration details (instance sizes, replication settings, networking topology). The plan accounts for this uncertainty with:

• Complexity tier classification to right-size the timeline (small: 2-4 weeks, medium: 6-10 weeks, large: 12-18 weeks)
• Wider success criteria thresholds scaled by tier
• Explicit recommendation to run IaC discovery before executing the plan

Prerequisites

Read the following artifacts from $MIGRATION_DIR/:

• aws-design-billing.json (REQUIRED) — Billing-based service mapping from Phase 3
• estimation-billing.json (REQUIRED) — Billing-only cost estimates from Phase 4
• billing-profile.json (REQUIRED) — GCP billing breakdown from Phase 1
• preferences.json (REQUIRED) — User migration preferences from Phase 2

If any required file is missing: STOP. Output: “Missing required artifact: [filename]. Complete the prior phase that produces it.”

Part 1: Context and Limitations

What Billing Data Provides

• Service-level monthly spend (which GCP services are in use)
• Relative cost distribution (which services are most expensive)
• AI signal detection (whether AI/ML services appear in billing)
• SKU-level hints about usage patterns

What Billing Data Does NOT Provide

• Instance sizes and configurations (CPU, memory, storage)
• Networking topology (VPC, subnets, firewall rules)
• Database engines and versions
• Replication and high-availability settings
• Inter-service dependencies
• Scaling configurations (min/max instances, autoscaling policies)
• Security configurations (IAM roles, encryption settings)

Recommendation

For a more accurate migration plan, provide Terraform files and re-run discovery. This billing-only plan is suitable for initial budgeting and stakeholder discussions, but must be refined with IaC discovery before executing the actual migration.

Part 2: Complexity-Scaled Timeline

Before building the timeline, load references/shared/migration-complexity.md and classify the migration tier using the inputs from aws-design-billing.json, billing-profile.json, and preferences.json.

Use the Billing-Only Path stage templates from migration-complexity.md for the determined tier. The three tiers produce different timelines:

Small Tier (2-4 weeks)

No parallel-run stage. Discovery and provisioning overlap. Suitable for migrations with <=3 services, <$1K/month, no databases, single-AZ, no compliance.

• Stage 1: Discovery + Provisioning (Week 1)
  • Quick audit of GCP infrastructure (few services, low complexity)
  • Provision AWS VPC, compute, and supporting resources
  • Configure IAM roles and security groups
• Stage 2: Deploy + Test (Week 2)
  • Deploy applications to AWS
  • Run functional and integration tests
  • Validate cost tracking against estimates
• Stage 3: Cutover + Validation (Weeks 3-4)
  • Execute cutover during maintenance window (DNS switch)
  • 24-hour intensive monitoring
  • Stabilization and GCP teardown planning

Medium Tier (6-10 weeks)

Shortened parallel run. Discovery takes 1-2 weeks instead of 4. For migrations with 4-8 services, $1K-$10K/month, or databases present.

• Stage 1: Discovery Refinement (Weeks 1-2)
  • Audit current GCP infrastructure
  • Document instance sizes, database configs, networking topology
  • Map dependencies between services
  • Refine AWS design based on discovered configurations
• Stage 2: Service Migration (Weeks 3-5)
  • Provision AWS infrastructure (VPC, compute, databases, storage)
  • Deploy applications, set up CI/CD pipelines
  • Integration testing and data migration dry run
• Stage 3: Parallel Run (Weeks 6-7)
  • Run both environments simultaneously
  • Compare performance, reliability, and costs
  • Validate data consistency
• Stage 4: Cutover and Validation (Weeks 8-10)
  • Execute cutover (DNS switch, traffic migration)
  • 48-hour intensive monitoring
  • Stabilization and GCP teardown planning

Large Tier (12-18 weeks)

Full conservative plan with extended discovery and parallel-run phases. For migrations with 9+ services, >$10K/month, multi-region, compliance, or AI alongside infrastructure.

• Stage 1: Discovery Refinement (Weeks 1-4)
  • Weeks 1-2: Manual infrastructure audit, dependency mapping, configuration documentation
  • Weeks 3-4: Refine AWS design, re-estimate costs, identify services needing different AWS targets
  • Consider running IaC discovery if Terraform files become available
• Stage 2: Service Migration (Weeks 5-9)
  • Weeks 5-6: Provision AWS infrastructure (VPC, compute, databases, storage)
  • Weeks 7-8: Deploy applications, set up CI/CD, migrate to staging
  • Week 9: Integration testing, performance baseline, data migration dry run
• Stage 3: Parallel Run (Weeks 10-12)
  • Run both GCP and AWS simultaneously
  • Compare performance, reliability, and costs
  • Validate data consistency between environments
  • Monitor for 2+ weeks before cutover decision
• Stage 4: Cutover and Validation (Weeks 13-15+)
  • Execute cutover (DNS switch, traffic migration)
  • 48-hour intensive monitoring
  • Stabilization and GCP teardown planning

Part 3: Risk Assessment

Risks are scaled by complexity tier. Use the Risk Scaling by Tier table in references/shared/migration-complexity.md to set probability values. The table below shows risk templates — replace the probability column with the tier-appropriate value.

Standard Risks

For the determined tier, include only risks with probability > “n/a”. Use the probability from that tier’s column.

Part 4: Per-Service Migration Steps

For each service in aws-design-billing.json.services[], generate a migration step template.

Migration Step Template

Example: Cloud Run to Fargate

Unmapped Services

For each entry in aws-design-billing.json.unknowns[]:

Part 5: Success Criteria

Thresholds scaled by complexity tier. Simpler migrations have fewer unknowns and tighter targets. Use the Success Criteria Scaling by Tier > Billing-Only Path table in references/shared/migration-complexity.md.

Apply the column matching the determined complexity tier.

Part 6: Output Format

Generate generation-billing.json in $MIGRATION_DIR/ with the following schema.

The example below shows a small tier migration. Adjust complexity_tier, complexity_inputs, duration_drivers, tier_bound_by, approach, phases, risk probabilities, and success metric thresholds according to the determined tier (see Part 2, Part 3, Part 5, and references/shared/migration-complexity.md).

Output Validation Checklist

• phase is "generate"
• generation_source is "billing_only"
• confidence is "low"
• complexity_tier is one of "small", "medium", "large"
• complexity_inputs object is present with all required fields (service_count, monthly_spend, has_databases, has_stateful_storage, has_ai_workloads, availability, compliance, multi_region)
• migration_plan.duration_drivers is a non-empty string array consistent with the tier’s driver table; tier_bound_by present; no total_weeks or hour fields
• migration_plan.approach matches tier: small = "compressed", medium = "standard_with_discovery", large = "conservative_with_discovery"
• migration_plan.phases stage names match the tier template from Part 2
• migration_plan.services covers every service from aws-design-billing.json
• risks array has at least 2 entries (small), 4 entries (medium), or 5 entries (large)
• Each risk probability matches the tier column from Part 3
• success_metrics thresholds match the tier column from Part 5
• recommendation.iac_discovery_offered is true
• recommendation.confidence is "low"
• recommendation contains no effort-hour fields
• Output is valid JSON

Completion Handoff Gate (Fail Closed)

Before returning control to generate.md, require:

• generation-billing.json exists and passes the Output Validation Checklist above.

If this gate fails: STOP and output: “generate-billing did not produce a valid generation-billing.json; do not continue Generate Stage 2.”

Generate Phase Integration

The parent orchestrator (generate.md) uses generation-billing.json to:

1. Gate Stage 2 artifact generation — generate-artifacts-billing.md requires this file
2. Provide billing context to generate-artifacts-docs.md for MIGRATION_GUIDE.md
3. Set phase completion status in .phase-status.json