• Replies 7 replies
  • Subscribers 69 subscribers
  • Views 1946 views
  • Users 0 members are here
Options
Related

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.

frank hardwick

I see plentiful documentation on moving to AWS Managed AD, but I'm not finding clear guidance on moving to AWS for the ARS Servers, SQL, Connectors, Domain Controllers, WITHOUT that "AWS Managed" portion.

My client plans to keep a full footprint in both Azure and AWS.

Anyone care to share some war stories or tales of success!

Frank

Parents

  • 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.

  • in reply to JohnnyQuest

    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".

  • in reply to frank hardwick_20260206090112

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

  • in reply to frank hardwick_20260206090112

    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

Reply
  • in reply to frank hardwick_20260206090112

    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

Children
  • in reply to geoff cranenburgh

    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