Migrate entirely from On-Premises AD to Cloud-Only Azure ADDS


  • Hi, I am an Office 365 tenant configured with Azure AD Connect AD synchronization back to my on-premise AD controller. All is working well with what I have configured today.

    In order to reduce overall operating expense and complexity, I'd like to fully migrate my AD infrastructure into Azure. I know I can set up a Windows 2012 VM and migrate my on-premise AD controller via VPN, but what I would prefer to do is utilize Azure Active Directory Services as my sole domain controller. I realize there is some reduced functionality but all of that is acceptable to us if it yields the benefits we are expecting it to in terms of reduced complexity.

    Are there best practices for migrating from my on-premise setup to cloud-only Azure ADDS? Is it as simple as stopping the directory synchronization between the two and creating a VPN connection into Azure to enable my client workstations authenticate to the Azure ADDS controller? Will the domain function without the current on-premise DC functioning?

    Thanks in advance for any advice or tips as I work through this.

    Thursday, March 23, 2017 3:37 PM

All replies

  • Azure Active Directory is not designed to be the cloud version of Active Directory. It is not a domain controller or a directory in the cloud that will provide the exact same capabilities with AD. It actually provides many more capabilities in a different way.

    That’s why there is no actual “migration” path from Active Directory to Azure Active Directory. You can synchronize your on-premises directories (Active Directory or other) to Azure Active Directory but not migrate your computer accounts, group policies, OU etc.

    As you can see here Azure Active Directory is an identity and access management solution for hybrid or cloud-only implementations. It can extend the reach of your on-premises identities to any SaaS application hosted in any cloud. It can provide secure remote access to on-premises applications that you want to publish to external users. It can be the center of your cross-organization collaboration by providing access for your partners to your resources. It provides identity management to your consumer-facing application by using social identity providers. Cloud app discovery, Multi-Factor Authentication, protection of your identities in the cloud, reporting of Sign-ins from possibly infected devices, leaked credentials report, user behavioral analysis are a few additional things that we couldn’t even imagine with the traditional Active Directory on-premises.

    Even the recently announced Azure Active Directory Domain Services are not a usual DC as a service that you could use to replicate your existing Active Directory implementation to the cloud. It is a stand-alone service that can offer domain services to your Azure VMs and your directory-aware applications if you decide to move them to Azure infrastructure services. But with no replication to any other on-premises or cloud (in a VM) domain controller.  

    If you want to migrate your domain controllers in the cloud to use them for traditional task you could deploy domain controllers in Azure Virtual Machines and replicate via VPN.

    So to conclude, if you would like to extend the reach of your identities to the cloud you can start by synchronizing your Active Directory to Azure AD. This is how you can do it in 4 clicks and a few minutes

    You can see other demo videos with more capabilities here

    Friday, March 24, 2017 9:22 AM
  • To further add to the answer already given. Whether you can do away with on-prem, and go all in on cloud depends on what you are running on-prem.

    If the O365 suite of products is the only thing you have been running Azure AD will serve your needs.

    If however you have a range of servers; VPN, SQL, Hyper-V, etc it's not quite as easy. Azure AD Domain Services has a matrix of supported workloads, (assuming the workload is moved to the cloud as well), but not everything that runs on a Windows Server will work with it.

    So, the best practice would be to make a list of everything you have running on-prem, and evaluate each of the services for cloud feasibility. (Which can be a tedious task if you have ten racks of servers in your basement.)

    Friday, March 24, 2017 2:41 PM
  • I am looking to solve the same problem. All our services are on O365 and we use onedrive for file storage and onedrive for business for document sharing. We technically have nothing on premised. But we have this AD sync set up on our on premise Windows server 2012 domain controller and Azure AD. This works well but I'd like to decommission the on premise server as we really do not need anything on the local network.

    Right now, all new user and user management are done on the on premise Windows server, which syncs with Azure AD. I'd like to migrate this functionality to Azure AD and discontinue the use of the Windows server.

    Will appreciate any help!

    • Edited by Dele_d Friday, December 1, 2017 1:21 PM
    Friday, December 1, 2017 1:18 PM
  • I am the opposite of an experienced Windows Server adminstrator.  I took the advice of my nephew who is one  (and recently hired by MS for field pre and post sales support).

    Having a similar case -- a small office (< 10 people) using predominately Office 365 but having a 'legacy' (nice word for falling apart and occasionally bootable) AD controller on-prem I took a huge leap of faith and migrated the office first to local workstations then to AWS Workspaces -- using only the Azure AD that comes with the basic Office 365 subscription.  

    An amazingly  problem-free task -- and has kept going without any significant effort for 6 months.

    I was able to 100% get rid of all the on-site 'servers' -- file server, Windows 2003 AD,  Sonicwall firewall (replaced by a open source business grade router), print servers, VMWare servers -- gone -- (well backed up multiple times and stored in the back office closet next to the toilet paper and box of old keyboards).

    Key Ingredient.  You need Windows 10 or equivalent on all workstations.  In my case, since I was moving all applications except the PCIOP client to 'the cloud' I backed up then wiped and installed Win 10 from scratch on all system.  I know enough to know I know too little to be sure there wasn't leftover 'bits' of the old AD configurations lying around waiting to get out and cause troubles.

    The steps I took -- ( YMMV)


    A) Attempt to UN ATTACH from the AD as many non-workstation type devices from whatever tangled web they have grown over time ... Printers, wifi routers, underwear -- who knows ... as much as I could I 'temporarily' disabled or unset whatever I could find that was unnecessarily associated with the AD.
    NAS drives, CD printers , anything with a wire or wifi even remotely possible to connect probably has some AD glue stuck on it ...  Unlike desktop OS devices these are usually easy enough to detach from the AD without throwing the out the window.  The hard part is *finding them*.

    When you tire of that -- time to get going ! Plan on a month.   It took me an hour (after #2).

    ( it took a few months to plan -- but only an hour to transition, not including dead-time such as windows installs ) 

    1) Backup EVERYTHING -- then backup those backups.  (I hate losing data).

    I had pre-prepped the employees to know I was no longer going to be backing up their workstations and they should have no work critical files on them, everything that wasn't already on the in-house or cloud shared servers was to be moved off.  An exception, I let the boss keep his own non-boot drive after he promised (multiple times) that I wasn't responsible for it in any way - including making his old 1990's 'personal' software be able run ...  It was unlikely to hurt anything.

    I had decided to move in one shot from fully on-prem to fully  in-cloud.  All apps were ready and installed and tested for remote access.  The app *data* needed to be moved in one shot so noone would have half-written files in multiple places.  In my case I moved the on-prem file server contents at the same time to the same drive mapping off-prem.   Then turned it off. (see#2)

    2) Turn off everything.   (could do one at a time, I took them all down at once).

    NOTE: I turned of EVERYTHING in the office except the router/firewall -- I know enough to not know enough to be safe otherwise.

    3) One by one, on each workstation reformat then install from scratch Windows 10 (pro)

    3A) On INITIAL INSTALL -- tell windows 10 to authenticate using your *work* email address (Office 365 login).

    3B) Login. Look for more things that need fixing.   Keep looking.  

    3C)  Not trusting I looked hard enough -- KEEP LOOKING -- 

    Nothing.  It worked. Done.

    4) Tell them you worked all weekend and its finally ready,  but it only really took an hour.

    Seriously, thats all.  It Just Worked.  No fancy domain vs DOMAIN vs WORKSPACE vs WTF nonsense.  No problems with not connecting to the AD and blocking you out, no problems of any kind at all. 


    5) well -- ok nothings PERFECT -- there were a few things I didn't have a clue about,  an old printer, a 'server' program running no one knew about but 5 months later a printer 'called home' and decided its license had expired -- 

    I also discovered things no one even guessed used some obscure feature of AD that Office 365 didn't support like Radius authentication from the Sonicwall.   Most of these were solved by simply getting rid of them.  For the most part the devices that were intricately hooked to AD were simply not needed anymore -- like the VPN, no need for a VPN if your 'workspace' isn't on-prem !  Same with the printers -- and 'shared file servers -- '  Either we didn't need them anymore (to backup the AD! ) or they worked just fine with simple authentication or none -- ( does it matter really if the $100 ink jet allows 'anyone' to connect to it ? when its not on the Domain -- not really).  

    What was left -- was either non-essential or it was time to upgrade it anyway. 

    9 months later -- no significant issues.  Nothing nearly as bad as when we had an AD on-prem ... No one noticed the difference except fewer logins and less 'Call the IT Guy to Fix It'

    Wednesday, January 10, 2018 7:12 PM
  • Hi Neelesh.

    Thanks for elaboration.

    I have question in mind,

    Are we adding On-Premise client machine (vm/physical/aws) to AZURE AD?

    As per the below doc, it says we can add AZURE VM to Azure AD


    For some internal project: In my case, am not going to deploy DC in any azure vm (traditionally).

    My end user wants, on premise vm to be added to azure ad,  can we?



    Wednesday, March 28, 2018 5:53 AM
  • Dharanesh, replicating your On-Prem environment to Azure IaaS model and synchronizing your On-Prem AD to Azure AD are completely different scenarios.

    1. You can spin up VMs in Azure and leverage them to create a mirror image of your On-Premise AD on Azure IaaS platform. For this, check: Guidelines for deploying Windows Server Active Directory on Azure virtual machines and Install a replica Active Directory domain controller in an Azure virtual network.

    This is possible with the Azure Active Directory Domain Services.

    2. Using Azure AD - would be to synchronize your On-Prem AD to Azure AD. This is done with the help of Azure AD Connect Tool. Check: Integrate your on-premises directories with Azure Active Directory

    And here's how the Subscriptions are associated with the Azure AD Directory. The Azure AD directory is like a container in which you can group users and subscriptions.

    Do click on "Mark as Answer" on the post that helps you, this can be beneficial to other community members.

    Wednesday, March 28, 2018 8:32 AM
  • I know this is a bit old but I had a question. How did you replicate your traditional file server (user access, permissions etc...) with seemless access from Azure AD?
    Thursday, October 18, 2018 4:30 PM