Starting on Synology does not trap you - but leaving it is a planned move, not an upgrade button. Here is the honest route offices actually take to Windows Server AD.
The fair question about the free Synology domain is what happens at year three, when the company has doubled. The honest answer: there is no trust relationship and no in-place promotion path between a Synology domain and a Windows Server domain. What exists is a well-understood parallel migration. This page lays it out so the Synology years read as a good first chapter, not a dead end.
Domain trusts are how migrations normally get their easy mode - two directories cooperate while you move people across. Synology Directory Server does not support trusts with Windows domains, and a Windows DC cannot join the Synology's domain as a controller. Tools like ADMT depend on exactly those mechanisms. So the migration is not a wizard; it is a new domain built beside the old one, with a planned cut-over. Knowing this from the start is precisely why the Synology decision stays honest.
Install Windows Server, promote it as a new domain (you may keep the same domain name plan or take the chance to tidy it), and build the OU and group structure fresh - using your Synology layout as the blueprint. Nothing touches the live office yet. Set DNS carefully so both worlds can be tested without colliding, and prove logins and Group Policy on two spare PCs first.
Recreate user accounts in the new domain (export the Synology user list as your checklist; passwords are set fresh - schedule a password-reset Monday). Because you granted permissions by group on the Synology side - the habit this series keeps recommending - file migration becomes: copy the data across with a tool like robocopy, then re-apply permissions to the matching new groups. Offices that granted permissions person-by-person discover the cost of that shortcut here.
Per PC: leave the old domain, join the new one, and migrate the user's local profile so their desktop and documents land under the new account (profile-migration utilities exist for exactly this step). Do a pilot desk on Friday, the office over the weekend, and keep the Synology domain running and untouched as the fallback for the first week. Staff sign in with new passwords on Monday; the old domain stays powered, read-only in practice, until every straggler is confirmed moved.
Do this when a real trigger arrives: the second site, the merger, the compliance demand, the new server purchase that makes Windows licensing natural anyway. Not before. And notice the Synology's second career: demoted from controller, it remains an excellent file and backup target inside the Windows domain - DSM joins Windows AD as a member happily. The hardware investment survives the migration; only the directory role moves house.
The video shows where the journey starts. If your office later outgrows it, this page is the map - and the NAS itself still has a job at the destination.
Watch Full VideoUsernames yes - recreate them identically. Passwords no - password hashes do not transfer between these two directories, so plan a coordinated password reset at cut-over. Tell staff early; it is a known, one-time cost of the move.
File permissions reference accounts in the old domain, so they must be re-applied to the new domain's groups after copying. If your Synology permissions were group-based (as this series recommends), that is a mapping exercise of an hour, not a week of archaeology.
Not at all. It joins the Windows domain as a member server and keeps doing the jobs it is best at - file shares, snapshots and backup target. Only the domain-controller hat moves to Windows Server.