Plan, Design and Migrate from your existing Organization


With introduction of AWS Control Tower to provision and manage multi- account AWS Environment, AWS has made it simpler to crate new AWS account and thus eliminating the need to manage AWS provided complex landing zone or any home grown solution.

AWS Control Tower combines and integrates the capabilities of several other AWS Services, including AWS Organizations, AWS Single Sign-on, and AWS Service Catalog.

AWS Control Tower has the following features:


The first step of enabling AWS Control Tower in your existing Organization is to setup a landing zone. AWS Control Tower needs to enabled on Management Account aka. Master account/Billing account.

Although when AWS Control Tower sets up the landing zone, it automatically runs a series of pre-launch checks in that account, the following consideration need to be made regarding AWS Config and CloudTrail


AWS Control Tower, be default create two OU — Core and Custom. It also creates two default account —

To set up your landing zone, AWS Control Tower requires two unique email addresses that aren’t already associated with the AWS account.

To test out account migration, I have setup the following Organization.

The plan is, the accounts in Dev OU will be created using Enrollment feature from AWS Control Tower Console.

Test OU accounts will be automated and existing accounts will be on Existing Account OU crated via AWS Organization. The migration phase will move these accounts to the Custom OU.


When the landing zone is set up successfully, you will find a successful configuration message in AWS Control Dashboard.

You will also get a SSO login url—, ff the SSO is not already not setup.

You need to log into the master account which you can do using the SSO login url above.

These prerequisites are required before you can enroll an account in AWS Control Tower:

Now to enroll existing account here from unregistered OU (Existing Accounts) to a registered OU (Custom) created in Control Tower, you can do via the following -

Enrollment using Account factory in AWS Control Tower

When you enroll accounts using this method, you must be signed into an account with an IAM user that has the AWSServiceCatalogEndUserFullAccess policy enabled, and you cannot be signed in as Root. The default Control Tower Administrator has got this permission.

The Enroll account capability is also available when your landing zone is not in a state of drift, which we will discuss later.

To use this capability:

Here Account email is the root account log in email. SSO user if not present will be created when default SSO directory is used and will be assigned AWSAdministratorAccess permission which allows FullAccess to that account. You can change it later.

Enrollment using AWS Control Tower Account factory product in Service Catalog

The user needs to have the permission AWSServiceCatalogEndUserAccess which default Control Tower Administrator will have.

Navigate to Service Catalog in AWS Console and select AWS Control Tower Account Factory from Products and click on the Launch product.

Give a product name which could be same as account name or select Generate name and fill in the required information in Parameters section as described in previous section.

Scripted Migration

AWS has provided a script to migration a single account or all accounts from an un-registered OU to registered OU.

To use this, the account you are using for AWS Log-in to must be added to the Account Factory Portfolio in AWS Service Catalog. I was using a local account for programatic access and needed to the add the use the Service Catalog Portfolio, although you can configure AWS SSO and log it using it.

I was getting the following error without the permission — No launch paths found for resource

Another cool feature of it, you can do pre-checks using the -V option before running migration -

python -i 1234567890 -o Custom -u "Existing Accounts" -V

It gave me the following result.

Rollback and Remediation

There are many causes for the account enrolment can be failed. The common causes are -

To find out the root case, view the error that you get. e.g. viewing the account from AWS Control Tower Console shows that sts is disabled -

The above error shows that indication that it failed due to sts not being enabled either in master or the target account. In my case it was master account that did not have sts enabled for the AWS region where AWS Controller is. Better is to enable it for all regions in case AWS Control Tower in introduced in another region.

We can also view the same from the provisioned product list in AWS Control Tower . In the Access Filter, remember to select Account to view all failure -

After that STS is enabled as in my above case, to remediate the issue, it is needed to run update — just select Actions -> Update from the same page while the account is selected and provide the existing information for the account name/email. You can change SSO user if needed.

In some cases, where you cannot just update the account which is in Error state. To remediate that you need to unmanage the account. Select the Actions -> Terminate. It will not terminate that account, just the account will be unmanaged which you can enroll again. After the product is successfully terminated, it will show as Not enrolled in AWS Control Tower -> Accounts

Drift Detection

If you change any configuration made by AWS Control Tower from outside of it, e.g. IAM role, OU name changes or moving account from one OU to another, it will be detected as drift by Control Tower automatically.

To resolve the drift you can either Rollback the changes made or select the Repair from Landing Zone settings — it will do full repair — both Landing Zone and Accounts. If you want to repair only a particular account, please follow the steps in the previous section.


I wish this document will help to migrate your organization to AWS Control Tower and help resolve the issues that you may get during migration. Please provide your feedback and clap to encourage.


Everything is Code