An end-of-life server gives no warning
A Windows Server 2012 or 2016 machine looks perfectly normal until the day a role fails. A poorly prepared Active Directory cutover can cut authentication for the whole organisation; a badly planned DHCP migration can stop IP address allocation across the network. These are not extreme scenarios, they are the classic traps of a server change made without a cutover plan.
Active Directory migration: promotion of the new domain controller, transfer of FSMO roles, clean demotion of the old server.
DNS and DHCP migration: zones, scopes, reservations, and a planned cutover to limit any break in IP allocation.
RADIUS / NPS migration (Wi-Fi and VPN network authentication): its scope depends on the certificates, network policies, Wi-Fi equipment, VPN, switches and Active Directory dependencies identified during the initial analysis.
Migration of file servers (shares, NTFS permissions, DFS) and print servers (queues, drivers).
Who is it for?
Small and medium-sized businesses still running a server at or near end of support (Windows Server 2012, 2016).
Organisations changing server hardware without changing operating system generation.
Organisations combining this migration with a move to virtualisation (see our virtualisation migration service).
Priced role by role
Each migrated role is priced separately, so you only pay for what you move. The starting price shown above corresponds to the simplest role. Active Directory, file servers (depending on data volume) and RADIUS / NPS (depending on the dependencies identified) are priced higher. The complete domain controller bundle (Active Directory, DNS and DHCP), the most common case, is priced as a package.
The cutover of the most sensitive roles (Active Directory, DNS, DHCP) usually takes place outside business hours, at night or at the weekend, so as not to interrupt your activity: that specific step carries a 50% uplift on the daily rate. Preparation and testing are done during business hours.
For organisations outside France, cutover windows are set in your local time and agreed at the planning stage.
How it works
Audit: inventory of the roles actually active on the source server and their dependencies.
Cutover plan: migration order, intervention windows and a rollback plan for each role.
Coexistence: the new server runs alongside the old one while each role is validated before the final cutover.
Cutover: actual transfer of the roles, usually outside business hours for critical roles.
Validation and decommissioning: checks, then decommissioning after a validation period if no blocking dependency is found.
The migration is carried out remotely, through the administration access you provide. If a step requires physical presence (rack mounting, cabling), it is identified at the planning stage and an on-site visit is possible on quote.
Deliverables
A detailed migration plan with role order and rollback plan.
A new server running with the migrated roles validated within the planned scope.
Documentation of the new configuration.
A migration report and follow-up recommendations.
14 days of post-cutover support for questions and minor adjustments related to the migrated roles.
Further reading
Frequently asked questions
Do you also migrate the certificate authority (PKI)? No. A badly migrated certificate authority can break the chain of trust of issued certificates (Wi-Fi, VPN, internal applications) for the whole organisation, sometimes with a delay. It is the most delicate migration of all, and we do not offer it as part of this service. A PKI specialist remains recommended for that specific role.
Can you migrate only some roles? Yes. Each role is priced separately: you can migrate only DNS and DHCP, for example, if Active Directory stays on the existing infrastructure.
Does this service guarantee zero downtime? No. Like any critical infrastructure migration, it is an obligation of means: the method (coexistence, tests, scheduled windows, rollback plan) greatly reduces the risk of incident without being able to eliminate it entirely.
How long before the old server can be switched off? We recommend a coexistence period, usually one to four weeks depending on the roles, before final decommissioning, to make sure no dependency has been forgotten. Keeping the old server beyond this agreed period is not included.
What does the 14-day support after cutover cover? Questions and minor adjustments related to the migrated roles. Business applications, scripts, specific printers, mapped drives, GPOs or undocumented dependencies must be identified during the initial analysis: application fixes or dependencies not directly linked to the migrated roles remain out of scope. The support includes no on-call duty, continuous monitoring, day-to-day server administration or recurring user support, and no purchase or supply of licences.