Pulumi Cdk To Pulumi

CRITICAL SUCCESS REQUIREMENTS

The migration output MUST meet all of the following:

1. Complete Resource Coverage

• Every CloudFormation resource synthesized by CDK MUST:
• Be represented in the Pulumi program OR
• Be explicitly justified in the final report.

1. Successful Deployment

• The produced Pulumi program must be structurally valid and capable of a successful pulumi up (assuming proper config).

1. Final Migration Report

• Always output a formal migration report suitable for a Pull Request.
• Include:
• CDK → Pulumi resource mapping
• Provider decisions (aws-native vs aws)
• Behavioral differences
• Missing or manually required steps
• Validation instructions

WHEN INFORMATION IS MISSING

If a user-provided CDK project is incomplete, ambiguous, or missing artifacts (such as cdk.out), ask targeted questions before generating Pulumi code.

MIGRATION WORKFLOW

Follow this workflow exactly and in this order:

1. INFORMATION GATHERING

1.1 Verify AWS Credentials (ESC)

Running AWS commands (e.g., aws cloudformation list-stack-resources) and CDK commands (e.g. cdk synth) requires credentials loaded via Pulumi ESC.

• If the user has already provided an ESC environment, use it.
• If no ESC environment is specified, ask the user which ESC environment to use before proceeding with AWS commands.

You MUST confirm the AWS region with the user. The cdk synth results may be incorrect if ran with the wrong AWS Region.

1.2 Synthesize CDK

Run/inspect:

npx cdk synth --quiet

• ALWAYS run synth with --quiet to prevent the template from being output on stdout.

If failing, inspect cdk.json or package.json for custom synth behavior.

1.3 Identify CDK Stacks & Environments

Read cdk.out/manifest.json:

jq '.artifacts | to_entries | map(select(.value.type == "aws:cloudformation:stack") | {displayName: .key, environment: .value.environment}) | .[]' cdk.out/manifest.json

Example output:

{
  "displayName": "DataStack-dev",
  "environment": "aws://616138583583/us-east-2"
}
{
  "displayName": "AppStack-dev",
  "environment": "aws://616138583583/us-east-2"
}

In the Pulumi stack you create you MUST set both the aws:region and aws-native:region config variables. For example:

pulumi config set aws-native:region us-east-2 --stack dev
pulumi config set aws:region us-east-2 --stack dev

1.4 Build Resource Inventory

For each stack:

aws cloudformation list-stack-resources \
  --region <region> \
  --stack-name <stack> \
  --output json

1.5 Analyze CDK Structure

Extract:

• Environment-specific conditionals
• Stack dependencies & cross-stack references
• Runtime config (context/env vars)
• Construct types (L1, L2, L3)

2. CODE CONVERSION (CDK → PULUMI)

• Perform the initial conversion using the cdk2pulumi tool. Follow cdk-convert.md to perform the conversion.
• Read the conversion report and fill in any gaps. For example, if the conversion fails to convert a resource you have to convert it manually yourself.

2.1 Custom Resources Handling

CDK uses Lambda-backed Custom Resources for functionality not available in CloudFormation. In synthesized CloudFormation, these appear as:

• Resource type: AWS::CloudFormation::CustomResource or Custom::<name>
• Metadata contains aws:cdk:path with the handler name (e.g., aws-s3/auto-delete-objects-handler)

Default behavior: cdk2pulumi rewrites custom resources to aws-native:cloudformation:CustomResourceEmulator, which invokes the original Lambda. This works but has tradeoffs (Lambda dependency, cold starts, eventual consistency).

Migration strategies by handler type:

Cross-account/region handlers:

• aws-cloudfront/edge-function → Use aws.lambda.Function with region: "us-east-1"
• aws-route53/cross-account-zone-delegation-handler → Use separate aws provider with cross-account role assumption

Graceful degradation for unknown handlers:

1. Keep the CustomResourceEmulator (default behavior)
2. Document the custom resource in the migration report with:

• Original handler name and purpose (if discernible from CDK path)
• Note that it uses Lambda invocation at runtime
• Recommend user review for potential native replacement

2.2 Provider Strategy

• Default: Use aws-native whenever the resource type is available.
• Fallback: Use aws when aws-native does not support equivalent features.

2.3 Assets & Bundling

CDK uses Assets and Bundling to handle deployment artifacts. These are processed by the CDK CLI before CloudFormation deployment and appear in the cdk.out directory alongside *.assets.json metadata files. CloudFormation templates contain hard-coded references to asset locations (S3 bucket/key or ECR repo/tag).

# Inspect asset definitions
jq '.files, .dockerImages' cdk.out/*.assets.json

Migration strategies by asset type:

Detecting Bundling in CDK Source:

Check the CDK source code for bundling constructs (NodejsFunction, PythonFunction, GoFunction, or resources using the bundling option). If bundling is used, the build step needs to be replicated in Pulumi for ongoing development - otherwise source changes would require manually re-running cdk synth.

When bundling is detected, inform the user:

Build Step Detected: This CDK application uses <BUNDLING_TYPE> which builds deployable artifacts during synthesis. This build step needs to be replicated in Pulumi for ongoing development. Options: 1. CI/CD Pipeline (Recommended): Move the build step to your CI pipeline and reference the pre-built artifact in Pulumi 2. Pulumi Command Provider: Use command.local.Command to run the build command during pulumi up 3. Pre-build Script: Create a build script that runs before pulumi up and outputs to a known location Each option has tradeoffs around caching, reproducibility, and deployment speed. For production workloads, option 1 is typically preferred.

2.4 TypeScript Handling for aws-native

aws-native outputs often include undefined. Avoid ! non-null assertions. Always safely unwrap with .apply():