When Microsoft Active Directory or Samba AD fits your estate
Samba AD fits a domain whose features it supports and whose team can run Linux domain controllers. Active Directory fits estates that depend on Windows-specific behavior, such as Group Policy managed at scale, Windows-integrated authentication across many applications, or DNS and replication designs the team already runs well. The decision usually starts with a Windows Server renewal or a licensing change, but the answer depends on what the domain actually does today, not on the license line item alone.
Four factors decide the outcome. The first is Group Policy and SYSVOL use: confirm which GPOs, logon scripts, and file-based policy content are in place, and test each one against Samba's supported behavior before committing. The second is the functional level in place, since Samba supports the 2008 R2, 2012 and 2012 R2, and 2016 levels, and the forest and domain levels must be inside that range before any migration path is viable. The third is DNS design, including whether the domain uses the SAMBA_INTERNAL or BIND9_DLZ backend and whether any application depends on DNS features outside those backends. The fourth is Windows client and application requirements, such as NTLM dependencies, smart card logon, and line-of-business software that expects Active Directory specifically.
Operating skills matter as much as features. A Samba AD domain is administered with samba-tool, and the Samba wiki advises against running an AD DC as a file server when multiple DCs exist, so file serving should move to separate domain members. Ask your team who will own patching, replication monitoring, and backup and restore for Linux DCs, and confirm those responsibilities in writing. Check the current Samba release series and its support window in the Samba release planning notes before you choose a version, since the series you deploy determines how long you receive full support.
Which estates Samba AD is a safe replacement for
This table maps common Active Directory estate profiles to the better fit, Samba AD or keeping Windows domain controllers, and the supplied facts behind each call. Read each row against your own domain controller count, functional level, file services and application dependencies, then test the cases that remain uncertain before committing.
| Estate scenario | Better fit | Reason and what to confirm |
|---|---|---|
| Linux-heavy estate with few Group Policy needs and a 2016 or lower functional level | Samba AD is a plausible candidate | Samba supports the 2016 functional level since Samba 4.20, and Group Policy needs are limited. Confirm that the Windows clients you still run do not depend on specific GPO settings or Windows-only management tooling. |
| Heavy Group Policy and SYSVOL use across many Windows servers | Keep Windows domain controllers | Group Policy and SYSVOL replication are areas where Samba AD gaps matter most. Ask the Samba documentation and your own tests to confirm each policy setting and replication behavior you rely on before any decision. |
| Domain already at the 2016 functional level with several Windows member servers | Samba AD, after a coexistence test | Samba can host the 2016 level since Samba 4.20, so the level alone is not a blocker. Run a joined test DC and verify every Windows client and member server login, GPO application and DNS resolution first. |
| Domain that also hosts file servers on its domain controllers | Separate file service first, then decide on Samba AD | The Samba wiki advises against using an AD DC as a file server when there are multiple DCs and recommends a separate domain member. Move file shares off the DCs and plan that change before any identity migration. |
| Estate needing vendor support for AD-dependent applications | Keep Windows domain controllers unless the vendor confirms support | Application vendors may certify only Windows domain controllers. Ask each vendor in writing whether Samba AD is supported for their product, and test authentication paths, service accounts and LDAP queries. |
| Estate with Windows client fleet and mixed application LDAP or Kerberos integrations | Test before deciding | Samba is an AD-compatible DC, but Windows client and application behavior must be verified in your environment. Build a test domain, then check domain join, Kerberos ticketing, LDAP bind patterns and password policy behavior. |
| Environment without in-house Samba and Linux administration skills | Keep Windows domain controllers for now | Running Samba DCs needs Linux, Samba and samba-tool skills for ongoing operations. Ask any implementation partner to document who will operate, patch and monitor the DCs after handover. |
Functional level, Group Policy and SYSVOL checks before a move
Before any Windows domain controller is replaced, the team needs a clear picture of the forest and domain it runs today. The cards below cover the checks that decide whether Samba AD can take over, and where the team must confirm current Samba behavior against the documentation for the release it will deploy rather than assume parity with Windows Server.
Current domain functional level
Start by confirming the domain and forest functional levels in the existing estate. Samba supports the Windows Server 2008 R2 level from Samba 4.0, the 2012 and 2012 R2 levels from Samba 4.19, and the 2016 level from Samba 4.20. Pick a Samba release whose support covers the level you have, and check that the release you plan to deploy still receives full support. Raising the level is a one-way change on the Samba side, so test the plan in a lab domain first.
Group Policy objects in use
Inventory every Group Policy Object, its links, its WMI filters and its security filtering, then sort them by what they do: security baselines, Windows client settings, drive mappings, software deployment, and scripts. Many of these depend on the Windows Group Policy client and on administrative templates, so Samba's partial handling of Group Policy becomes a risk for each policy you cannot reproduce. Confirm the current Samba Group Policy coverage in its documentation, and test each policy category on a non-production client.
SYSVOL replication across domain controllers
SYSVOL holds the Group Policy templates and logon scripts that every domain controller must serve consistently. Record which replication mechanism your current domain uses, then verify how the Samba DCs in your test domain replicate SYSVOL with the Windows DCs during coexistence. Confirm the current Samba documentation for SYSVOL replication, because gaps here can leave a policy present on one DC and missing on another. Compare file hashes across all DCs after each change before you retire a Windows DC.
File serving on domain controllers
List every file share hosted on a domain controller, including home folders, department shares and print-related paths. The Samba wiki advises against using an AD DC as a file server when there are multiple DCs, and recommends a separate Samba domain member for file serving. Plan new file server hosts before the move, migrate shares, and update drive mappings and Group Policy that point to the old paths. Test permissions and access-based enumeration on the new hosts.
Schema extensions from third-party apps
Check the AD schema for extensions added by applications such as email, identity governance, backup, printing and endpoint products. Each extension adds attributes or classes that the application expects to find, and Samba AD may not hold them in the same way. Ask each vendor whether its product supports a Samba AD domain and which schema objects it reads or writes. Keep a list of required attributes so you can confirm that each one exists after the coexistence phase.
Windows client behavior
Test domain-joined Windows clients against the Samba DC in a lab before you move any production workstation. Check logon, Kerberos ticket issuance, NTLM fallback, DNS registration, Group Policy application and certificate auto-enrollment. Record the Windows client versions in use and the Windows features that depend on AD-specific behavior. Ask for the test results in writing before you approve the move for each client group.
Capability comparison from supplied facts
This table sets Microsoft Active Directory Domain Services against Samba AD across the capabilities that decide whether a domain controller can be replaced. Read each row as a question to answer for your own estate, and confirm current behavior for the Samba release you plan to deploy, since functional level and DNS details change between series.
| Capability | Microsoft Active Directory Domain Services | Samba AD |
|---|---|---|
| Directory role | Windows Server role storing users, computers and other objects | Samba AD DC on Linux storing the same object types in a domain |
| Replication to every DC | Replicates directory data to every domain controller in the domain | Replicates directory data between Samba DCs; confirm behavior when mixing with Windows DCs during coexistence |
| Schema and global catalog | Provides a schema, a global catalog and query and index mechanisms | Provides AD-compatible schema handling; confirm global catalog and index behavior for your version and applications |
| Kerberos | Windows Kerberos implementation integrated with the domain | Heimdal KDC by default; experimental MIT Kerberos support from Samba 4.7 when built with the system MIT library |
| DNS backends | Integrated DNS within the AD DS deployment | SAMBA_INTERNAL and BIND9_DLZ are supported; NONE is discouraged and BIND9_FLATFILE is not supported |
| Functional levels | Set by the Windows Server version of the domain controllers | 2008 R2 since Samba 4.0, 2012 and 2012 R2 since Samba 4.19, 2016 since Samba 4.20 |
| Administration | Windows management tools such as AD Users and Computers and Group Policy Management | samba-tool command line, including raising functional levels; confirm which Windows GUI tools you still need |
| Group Policy and SYSVOL | Group Policy objects replicated through SYSVOL to all DCs | Group Policy support and SYSVOL replication differ from Windows; test every policy you rely on before cutover |
| Linux client joins | Linux needs third-party tools or Kerberos realm configuration to authenticate against AD | Linux machines join as Samba-managed clients using the domain's Kerberos and LDAP services; confirm your SSSD or Winbind setup |
Who should move to Samba AD and who should wait
This model fits when a team already runs Linux servers confidently, the Windows clients mainly need domain logon, file access and printing, and the estate has little dependence on Windows-only server roles. A Samba AD domain controller is administered with the samba-tool command and standard Linux tooling, so the operators must be comfortable with that workflow, with Kerberos, DNS and replication troubleshooting, and with patching a Linux DC on a regular schedule. Samba supports the 2008 R2, 2012 and 2012 R2, and 2016 functional levels, so confirm that the domain's current level falls within that range before you plan the move.
- Clients stay simple: Domain-joined Windows workstations that only log on and map shares are the lowest-risk profile.
- File serving is separated: The Samba wiki advises against using an AD DC as a file server when there are multiple DCs, so plan separate domain member servers for file shares.
- Skills are in-house: Someone on the team must own DNS, Kerberos and replication without a vendor escalation path.
- DNS backend is chosen early: Use SAMBA_INTERNAL or BIND9_DLZ, avoid NONE, and note that BIND9_FLATFILE is not supported.
- Windows features still need checking: Any Windows-only server role or application that expects a Microsoft DC feature should be tested before cutover.
Before committing, confirm with your own engineers and with any application vendors that the workloads on the domain have been tested against Samba, and rehearse a full DC retirement in a lab first.
This model fits poorly when the organization depends on Group Policy for desktop lockdown, software deployment, security baselines or server configuration across many Windows machines. Group Policy and SYSVOL replication are where Samba's compatibility most often needs to be verified against your actual policies rather than assumed. Policies that use specific administrative templates, client-side extensions or Windows-only settings can behave differently or not apply at all, so the migration should start with an inventory of every GPO and its purpose.
- Policy inventory comes first: List each GPO, its links, its filtering and its client-side extensions, then mark which ones you can test on Samba.
- SYSVOL replication needs a test plan: Validate that policy files replicate across all DCs and that clients receive updates after a change.
- Windows Server management tools: Administrators who rely on Microsoft's GPMC and related tooling will need an equivalent workflow for daily operations.
- Rollback path: Keep at least one Windows DC until every policy has been proven on Samba, and plan the demotion checks in advance.
- Desktop image dependency: Organizations that manage desktops almost entirely through Group Policy may need a different management approach for the endpoints.
Confirm with your Windows and desktop engineering leads which policies are business critical, and test each one on a non-production domain before treating Samba as a replacement.
This model fits organizations in banking, healthcare, public sector or critical infrastructure where an auditor or regulator expects a named vendor to stand behind directory services, patch timelines and incident response. Samba is free software under GPL-3.0, and the Samba release planning gives each series six months of full support, six months of maintenance and six months of security fixes only. Those phases are the project's published cadence, not a commercial support commitment, so an organization needs to decide where production support will come from before it relies on Samba for regulated authentication.
- Support source must be named: Decide whether support comes from an internal team, a commercial Samba support provider, or a service partner, and get that in writing.
- Release cadence affects control evidence: Map the Samba series in production to the security fix window so patch evidence can be produced for auditors.
- Control mapping: Document how directory controls such as account lifecycle, password policy and privileged group changes are implemented and logged on Samba.
- Change management: Regulators may expect tested change and rollback records for a domain controller migration.
- Independent assessment: DeployOpen prepares systems and evidence for compliance assessments, but auditors and certification bodies issue any report.
Ask the internal audit team which control objectives the directory must meet and whether a Samba-based design is acceptable under the organization's own framework.
What drives the Windows Server and CAL cost against Samba
The cost of keeping Windows domain controllers is mostly a licensing question, and the Samba side of the comparison is mostly an operating question. Microsoft licenses Windows Server 2025 per core, with a minimum of 16 cores per server and 8 per processor. Both the Standard and Datacenter editions also need a Windows Server Client Access License (CAL) for every user or device that accesses the server. Microsoft's pricing page lists suggested prices of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter, each for 16 core licenses, and notes that prices vary by region. It also offers pay-as-you-go licensing through Azure Arc at 33.58 US dollars per core per month. Ask your Microsoft partner or reseller for a quote built from your own core counts, edition and device counts, and confirm whether Software Assurance or Azure Arc billing changes the figure for your agreement.
Samba AD does not require a Windows Server core license for the domain controller itself, because it runs on a Linux distribution. That removes the core license line for the directory role, but it does not remove the CALs. Any other Windows server that your users reach, such as file, print or application servers, may still need CALs for each user or device, so the saving only applies to the domain controller licenses unless those servers are also retired or moved. Map each Windows workload to its own licensing basis before you model the saving. Also confirm the Linux OS subscription terms for the distribution you choose, since some vendors charge for support and others do not.
The one-time costs are migration, testing and the skills needed to run the directory. Joining Samba DCs to an existing domain, checking the functional level, moving FSMO roles, validating SYSVOL and idmap behavior, and testing every Group Policy and Windows client path take project time that scales with the number of domain controllers, Group Policy objects and dependent applications. Recurring costs are operating labor for patching, monitoring, backup and replication health, plus any commercial support contract you add. A support contract is optional but worth pricing for regulated estates. Ask every vendor or partner to itemize one-time and recurring work separately, to state which Windows servers and CALs stay in place, and to show the assumptions behind each estimate.
Where directory data lives and who controls it
Moving from Active Directory Domain Services to Samba AD changes who runs the directory, where its data sits and who produces the evidence auditors ask for. The cards below cover the license, the release cadence, the operating duties that move in-house and the checks to make before committing.
Directory data stays in your hands
A Samba AD domain runs on servers you choose, in your data center or your cloud accounts, so the directory database, SYSVOL and domain controller disks sit under your access controls. Nothing about the directory is hosted by Samba or by DeployOpen unless you contract that separately. Confirm where each domain controller runs, which accounts can reach the hypervisor or cloud console hosting them, and who holds the keys for disk encryption.
Backup and patching move in-house
With Windows Server, Microsoft's lifecycle and update channels set the cadence for domain controller patches. With Samba, your team selects the release, tests it and applies it, and it owns backup and restore of the domain. Document the backup method for each domain controller, test a restore of a single DC, and assign a named owner for security updates before the first Samba DC joins the domain.
GPL-3.0 license terms
Samba is licensed under GPL-3.0, so you can run and modify it without a per-core or per-user license for the domain controllers. The obligations attach to distribution of modified code, which most internal deployments do not trigger, but your legal team should confirm how that applies to any custom patches or packaged builds you ship. Ask your Linux distribution vendor which Samba packages it supports for AD DC use.
Release cadence sets your upgrade plan
Each Samba release series receives six months of full support, six months in maintenance mode and six months of security fixes only. Samba 4.25 starts in September 2026, and the current stable release is 4.25.0 with 4.24.8 also available. Plan a standing upgrade cycle, because a domain controller on a series that has reached security-only status still needs patches but no longer gets feature or general bug fixes.
Audit evidence is produced in-house
Access reviews, privileged group membership reports and change records for a Samba domain must be exported and retained by your team, because no vendor console produces them by default. Decide which samba-tool queries, log exports and approval records serve as evidence, store them outside the domain they describe, and test that a reviewer can reproduce them. Compliance outcomes come from independent auditors and certification bodies, not from Samba, DeployOpen or any single tool.
Confirm the support model before cutover
Samba is community-supported unless you buy support from a vendor or partner, so the support contract is a separate decision from the software license. Ask any provider you evaluate which Samba versions they support, how they handle security advisories, what response times are written into the contract and whether they support multi-site replication. Get those answers in writing before you retire the last Windows domain controller.
Operating effort and skills to run Samba DCs
Once the last Windows domain controller is retired, the operating work moves to your own team, and it is different from running AD on Windows Server. Day-to-day administration runs through the samba-tool command, which covers users, groups, replication checks and functional levels, so runbooks and scripts written for Active Directory PowerShell will need rewriting. The decision with the longest tail is the DNS backend. The SAMBA_INTERNAL backend is the simplest to run, while BIND9_DLZ brings BIND tooling and its own patch cycle. Avoid the NONE backend, and confirm with the Samba wiki's current guidance which backend fits your zone layout before cutover, because changing it later is a planned project rather than a setting change.
Release maintenance is the recurring cost most teams underestimate. Each Samba release series gets six months of full support, six months in maintenance mode and six months of security fixes only, so you need a written schedule for moving DCs to each new series before the current one drops out of full support. Monitoring should cover DNS answers, replication health, Kerberos ticket issuance, and time synchronization, since Kerberos depends on tight clock alignment between DCs and clients. Confirm with your Kerberos and NTP configuration owners how time sources are set on every DC, and test failover of a single DC in a lab before you rely on it in production.
The skills gap is mainly in Linux administration, Samba internals and replication troubleshooting, not in AD concepts. Your staff need to read Samba logs, diagnose samba-tool drs replication failures, and understand how SYSVOL is kept in step across DCs. Ask whether your current team has run a Samba DC in production, and plan for training or an operations retainer if not. A retainer can cover monitoring, patching and incident response, while internal training builds the knowledge to handle routine work yourself. Either way, document who is paid for which tasks, and ask any provider for the written scope of support and escalation before you sign.
How a move from Active Directory to Samba AD runs
This sequence moves a Windows domain onto Samba domain controllers in an order that keeps the existing domain working at every stage, so each Windows DC is retired only after the checks pass. The detailed coexistence procedure sits on the sibling migration page, and every step below needs written acceptance criteria before work starts.
Inventory the domain and its dependencies
Record the current forest and domain functional levels, every DNS zone and its replication scope, all Group Policy Objects and where they link, the state of SYSVOL and NETLOGON on each DC, file servers and shares that depend on the domain, and any third-party schema extensions from vendors. The inventory is complete when the directory team and the application owners have signed off on a list that accounts for every item, and each item has a named owner and a decision: migrate, rebuild, or retire. Schema extensions and GPO features that Samba does not implement are flagged here, not discovered later.
Build a test domain
Stand up an isolated Samba AD DC lab that mirrors the production functional level, DNS backend and a representative set of GPOs, then join a test Windows client and a test Linux host. The lab is the place to validate the Samba version you intend to run, since release support windows differ by series. It is complete when the team can log on, apply policy, resolve names and run the application test cases against the lab, and the results are recorded against the acceptance criteria written for this phase.
Join Samba DCs and verify replication
Provision additional Samba DCs into the existing production domain following the Samba coexistence procedure, then confirm that directory replication, DNS and SYSVOL replication converge across Windows and Samba DCs. Check replication status and error logs on every DC, and confirm that a user created on one side resolves on the other. This step is done when replication shows no errors over the observation period agreed in the written acceptance criteria and the team has tested a failover of the Samba DC.
Confirm functional level support
Compare the domain and forest functional levels against the levels Samba supports before raising anything. Samba supports the Windows Server 2008 R2 level, the 2012 and 2012 R2 levels, and the 2016 level in the Samba release that adds each one, so the target level must be confirmed against the exact Samba version in use. Check the Samba wiki's guidance on raising levels, and record in writing the level the domain will run at. Do not raise the level until the rollback path is documented, because raising it is not a step you can casually undo.
Transfer FSMO roles and move file serving
Transfer the Flexible Single Master Operations roles to Samba DCs one at a time, verifying each transfer with the directory tools before the next. In parallel, move file shares off domain controllers onto separate Samba domain members, because the Samba wiki advises against using an AD DC as a file server when multiple DCs are present. This step is complete when every role is held by a Samba DC, every share is served from a member server, and permissions and access tests pass for sample users from each department.
Test Windows clients, Linux hosts and applications
Run the test cases from the inventory against production-like clients: domain logon, Group Policy application, printing, mapped drives, Kerberos single sign-on, LDAP binds from line-of-business applications, and any integration that depends on a schema extension. Test Windows and Linux clients separately, because their policy and authentication paths differ. The step closes when every test case has a recorded pass against its acceptance criteria, and any failure has a fix and a retest, not a waiver.
Demote the last Windows DC after sign-off
Only after the earlier checks pass and the business owners have signed the acceptance record, demote the remaining Windows domain controllers, starting with the last one as the final step. Confirm again that replication, DNS, authentication and file access work on Samba alone, and keep a verified backup and the rollback plan available until the sign-off period ends. This step is complete when the Windows DC has been removed cleanly, the domain health checks pass on the Samba DCs, and the change record shows who approved each decision.
Questions buyers ask before moving domain controllers
Can our team move domain controllers to Samba AD without outside help?
It depends on your Linux and Samba skills and on how heavily the domain uses Group Policy and SYSVOL. A team that already runs Linux servers, understands Kerberos and DNS, and can test Group Policy behavior on a copy of the domain has a realistic path to doing it alone. A team that has never administered a Samba AD DC should expect a learning curve before touching production. Ask yourself who will own the DNS backend, SYSVOL replication and the demotion of the last Windows DC after the cutover, and whether those people have tested those steps on a non-production domain.
How long does a move from Active Directory to Samba AD take?
The duration depends on the size and age of the estate, the number of applications that authenticate against the domain, the Group Policy objects in use, and how many change windows the business allows. No general timeline applies to every domain, so treat any single number you hear as unverified. Ask any provider for a fixed-scope written plan that lists phases, deliverables, test exit criteria and the work each side must complete. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
What does a Samba AD migration cost compared with keeping Windows domain controllers?
The cost has two sides. On the saving side, Windows Server 2025 is licensed per core with a 16-core minimum per server, and Standard and Datacenter editions both need client access licenses for users and devices that access the server. Microsoft's pricing page lists suggested prices, which vary by region, so confirm the figures for your agreement. On the other side, you pay for the migration itself: design, test domain build, application testing, cutover, training for Linux and Samba administration, and ongoing support. Licenses for other Windows servers and clients may still apply after the domain controllers leave. Ask for a quote that separates one-time migration effort from recurring support and operations.
What does our organization need to provide for a domain controller migration?
You need a non-production test domain that resembles production, scheduled change windows for each cutover step, and named owners for every application that authenticates against Active Directory. Application owners must confirm which LDAP, Kerberos or NTLM dependencies they have and sign off on test results. You also need access to the current domain, including schema and Group Policy inventories, and someone who can make decisions when a legacy application fails. Without these inputs, the migration usually stalls at the testing stage, so confirm them in the written scope before work begins.
Can Samba run as the only domain controller in our domain?
Samba can operate as an AD domain controller, but it should be the only controller only after you have completed the checks for functional level, SYSVOL and DNS and confirmed that every dependency works. Samba supports the Windows Server 2008 R2 functional level from version 4.0, the 2012 and 2012 R2 levels from 4.19, and the 2016 level from 4.20, so the domain's functional level must be one Samba supports. Samba's wiki also advises against running an AD DC as a file server when multiple DCs exist, so move file serving to a separate domain member. Confirm the current release and its support window before you choose a version.
Can Samba replace AD FS or Microsoft Entra ID roles in our environment?
No. Samba AD provides directory, Kerberos and DNS services for domain-joined machines and LDAP or Kerberos applications, while AD FS is a federation server and Entra ID is a separate cloud identity service. Microsoft's comparison notes that SaaS apps need a federation system such as AD FS, and that existing Active Directory organizations use Microsoft Entra Connect to sync to Entra ID. If you use either of those, plan a separate replacement, for example with an open-source federation server, and confirm with the vendors how sync and federation behave once the domain controllers change.
Does DeployOpen issue audit reports for a domain controller migration?
No. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms, and it prepares systems, controls and evidence for compliance assessments. Audit reports, attestations and certifications are issued by independent auditors and certification bodies. For a migration, that means DeployOpen can prepare configuration records, access reviews, backup and recovery evidence and test results for your auditor to examine, but your auditor decides what those records prove. Ask your auditor early which evidence they expect to see.
How DeployOpen helps evaluate and move a domain
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Microsoft Active Directory vs Samba AD, we start by testing whether your estate fits Samba AD before any domain controller is touched.
How we scope
- Inventory domain controllers, functional levels, FSMO roles and the Windows versions they run.
- Map Group Policy objects, SYSVOL contents, DNS zones and file services that depend on the domain.
- Agree in writing which Windows clients, applications and Linux hosts must still authenticate after the move.
How we build
- Build a lab Samba AD domain that mirrors your functional level and DNS backend choice before any production change.
- Test Group Policy replacements, SYSVOL replication behavior, idmap settings and Windows client join and logon.
- Document each gap found, with the workaround, the owner and the decision needed from your team.
How we hand over
- Deliver runbooks for samba-tool administration, role transfer, backup and restore, and demotion checks.
- Provide a written record of tests run, results and open risks for your security and compliance reviewers.
- Walk your administrators through operating the new domain, with the checks to complete before retiring the last Windows DC.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask any quote to itemize scope, deliverables, testing effort and retainer terms so costs can be compared.
