Enhacement | Specify strategies and conditions to import legacy/existing AWS accounts to code

[manuel-quinteros-binbash]

What?
Update doc to specify what is the best strategy when the client has existing or legacy AWS accounts that we need to include in the new AWS org landing zone, depending on the scenario.

Notes:

• Prod migration should be considered as last option
• Important to have a clear understanding about what services are running in the client's legacy/existing account/s.
• Preference to import a prod account to the existing organization evaluating the possible connections that account may have with other resources outside of it (other AWS accounts or integrations)

Doc to be updated: https://leverage.binbash.co/user-guide/ref-architecture-aws/features/organization/legacy-accounts/

Why?
It's important to have a clear path and know what is the best approach when it comes about managing client existing accounts, to avoid affecting their running workloads or integrations, increasing cost and migration efforts if existed.

[exequielrafaela]

🔧 Proposed Update for Legacy AWS Account Import Strategy

Refined approach to managing legacy AWS accounts in the Landing Zone:

---

🧭 Core Strategy

• Prefer importing legacy/prod accounts as-is
  Import the customer’s existing root or management–prod account into the new organization via AWS Organizations, without migrating workloads. This avoids downtime, reduces risk, and respects integrations such as cross-account resources, billing links, and infrastructure dependencies.
  ([docs.aws.amazon.com]1, [aws.amazon.com]2)

• Create fresh dev/test/stg environments and shared, security, network, data-science accounts
  To prevent conflicts and enable clean governance, spin up new dev or lower-tier accounts within the Landing Zone and migrate only non‑prod workloads, shared and security services over time.

• Reserve migration of production workloads as a last resort
  Migrating resources across accounts has high complexity and risk—it should only be considered when absolutely necessary and planned with full client coordination.
  ([dev.to]3)

---

🔍 Key Considerations

Topic	Rationale
Billing	Member account incurred charges move to the new mgmt account post-import. Shared credits and Reserved Instance behavior align with consolidated billing rules. ([docs.aws.amazon.com]4)
Service Controls	SCPs apply immediately upon join—ensure production workloads aren’t inadvertently restricted.
Cross-Account Dependencies	Inventory all service linkages (e.g., RAM, CloudWatch Events); ensure continued connectivity post-import.
SCP Access Roles	Manual recovery of OrganizationAccountAccessRole may be needed, since invites don’t auto-create it like brand-new accounts do.
AWS RAM Resources	Shared resources must be identified and re-shared if needed after account migration.
Credit & RI Sharing	Credits redeem in member account through month-end; afterward applied org-wide. Sharing preferences configurable via billing console.

---

✅ Recommended Documentation Updates

In the [Legacy Accounts import guide](https://leverage.binbash.co/user-guide/ref-architecture-aws/features/organization/legacy-accounts/), please add:

1. Import-as-Code-plus-Ops-Account strategy
   Import infra-as-code from existing prod accounts, retain workloads in-place, and build new development accounts fresh within the LZ.

2. Detailed considerations around:

   • Billing and shared credits
   • Cross-account resource dependencies
   • Service Control Policies and immediate gating
   • RAM re-sharing needs
   • AWS Organizations invite quotas and flows

These updates will clarify customer expectations, accelerate SOW drafting, and ensure we’re capturing the right details early—while still allowing flexibility for later workload migration if truly required.