I'm looking for guidance and/or warnings about migrating an existing Active Roles (managing 3 forests) to a greenfield in AWS but not AWS Managed AD.

Ok... I'll let you know what I learn.

Is this the sort of thing you are looking for:

Migrate an on-premises VM to Amazon EC2 by using AWS Application Migration Service - AWS Prescriptive Guidance

It's worth noting that AWS implements its own database server workload that **emulates** SQL - the emulation is not 100% and I have experienced permissions related issues when you try to use SQL tools to assign permissions - i.e. you need to use the AWS management tools if you choose to go in that direction.

The current ARS implementation has some "issues and baggage" that we wish to leave behind.  It was built in one forest, migrated to another, and more.  For that reason, we've spun up 4 shiny new EC2 servers in AWS behind a load balancer and MS SQL server that will be shared with other infrastructure projects IF that is what we MUST do.  We want to basically lift and shift the configuration into the new platform.  I'm looking at the Configuration Transfer Wizard to hopefully accomplish the "migration".

Yes this Wizard can certainly facilitate what you are looking to do - including leaving behind unwanted aspects of the current configuration.

Hello Frank,

My personal thoughts only are that I am not that confident with Lift and Shift working as thoroughly without qualifying what that means. Let's say you mean just the Database (Amazon RDS for SQL Server or Amazon Aurora) Without first tuning the PaaS before you lift and shift the databases you may run into performance issues. In addition, as you noted, that you are going to be using a shared infrastructure, if you are sharing workloads then you need to consider the difference in tuning requirements: transactional/operational and analytics workloads.

I feel that you migration path may be cleaner if you do an in-parallel upgrade. That is, you keep the existing environment as-is, build a new environment on the upgraded AR and migrate the database to the new environment, slowly migrate all the customization and test thoroughly. At least you will have a fallback plan to a working  environment. Then, when you are done you have two choices with the old environment. Either you decommission it or, as I have done sometimes, use it to test an in-line upgrade. If successful - it's dev/test; if not you decommission it.

Cheers

Geoff

Hi Geoff.  You make a lot of good points, so here is some clarification additional thoughts. 

I agree with parallelism, so the new ARS is being built (4 servers + SQL) while the existing one is in use. 

We're not just importing the entire database so that we don't bring all of our old "stuff" with us.  I'm planning to use the Config Transfer Wizard to selectively bring over the functional data: Managed domains, policies, templates, etc.

I have a concern about how to use old ARS and new ARS side by side on the same managed domains without triggering the law of unintended consequences.

The tool is working fine currently, but has had years of neglect and several admins with different views.

Thanks for your time and input.

F

Hi, Frank.

It happens that I just finished assisting a customer going through this precise type of scenario: migrating away from an old and established instance of the product to a new one in a new forest. Like with your customer, they had some issues with the old one that they wanted to leave behind, so opted to migrate to a new instance & new forest.

There was a lot involved in that project, including updating and migrating dozens of scripts that referenced the legacy environment name & OU structure, but one of the bigger pieces was probably the migrating of dynamic groups. All of the queries for the dynamic groups (and there were many) were based on an OU structure that didn't exist in the new environment, so the queries all had to be updated to reflect attributes (virtual or otherwise) instead of OU. To this end I created some fairly intensive scripts to translate and reconstruct the LDAP queries for all of the dynamic groups.

This was a fairly labour-intensive project; it's possible, but the customer needs to understand the scale of what such a project entails.

If your new environment uses the same OU hierarchy, obviously things will be considerably easier. The Configuration Transfer Wizard should help, but bear in mind that it does not transfer Workflow (or at least it did not the last time I looked at it, which was a while ago). If you use that, also be careful to import in the correct order. E.g., you need to import virtual attribute definitions before Policy or Access Templates, since the Policy/Templates can reference the virtual attributes.

Best of luck!