Feature request: support migration from older CloudFormation-deployed forwarders

[marekaf]

Context

A lot of long-running AWS accounts still have the Datadog Forwarder deployed via the
older CloudFormation template
(e.g. forwarder version 3.x, python3.10, x86_64), often with many production triggers
(S3 notifications, CloudWatch Logs subscriptions, SNS, EventBridge) bound to the
function ARN.

With AWS Lambda's python3.10 deprecation coming on 2026-10-31, those of us on the
older stack are looking at migration paths. Moving to this Terraform module is the
obvious long-term destination, but the current path isn't smooth.

The problem

Two things in the module are hard-coded with no override:

• runtime is forced to python3.13 or python3.14 depending on layer_version
  (main.tf)
• architectures = ["arm64"] is fixed

That means a TF-module-managed forwarder can't be deployed to match the
existing CFN-managed one. The practical consequences:

1. No clean import. import {} blocks plus the module would still produce a plan
   that rewrites runtime, swaps architecture (which forces Lambda replacement), and
   restructures IAM — all on a live function under load. The replacement loses the
   function ARN, taking out every existing trigger.

2. No "shadow" deploy with strict equivalence. Even running side-by-side, the
   new function differs in runtime+arch from day one, so any behavior delta observed
   during validation can't be cleanly attributed to "TF vs CFN" vs "python version"
   vs "architecture".

3. No staged migration. Today you have to do "switch tools + upgrade runtime +
   change architecture" in a single cutover, which is harder to roll back.

What would help

Any of these would unblock a cleaner migration; in rough order of preference:

1. Make runtime and architectures configurable (perhaps gated behind a
   legacy_mode = true variable or similar, since you presumably don't want to
   actively support python3.10 long-term — just enable a clean migration).

2. A documented migration guide in this repo showing the recommended approach for
   users coming from the CFN stack — whether that's side-by-side + cutover, partial
   import using existing_iam_role_arn / dd_forwarder_existing_bucket_name /
   dd_api_key_secret_arn, or something else.

3. An "adopt" mode that supports importing an existing forwarder Lambda and
   reconciling its configuration gradually (runtime upgrade as a follow-up apply,
   not the import-time apply).

Workaround we're using

We're going to deploy a parallel TF-managed forwarder with the module's required
defaults (python3.13/3.14 + arm64), cut triggers over one at a time, then remove
the CFN stack. Works, but the architecture/runtime jump rides along with the tool
migration, which we'd have preferred to keep separate.

Happy to help test any of the above if useful.