Identity Director Sync – Synchronization, continued.

Microsoft built MIM Sync, and for twenty years it did the job. Support ends in January 2029 – the job doesn’t. Identity Director Sync carries it on.

Your management agents, your extensions, your joins – Sync takes them over as they are: same concepts, same objects, same database, your code unchanged. Then it goes where MIM never went: a browser instead of a remote desktop, schedules instead of scripts, sync rules and provisioning without a portal, an API for everything. On your servers, in your data centre, with a date you can plan around.

In production today in financial services, healthcare and government. Available from 1 September 2026 through certified partners, general availability 1 January 2027.

As close as possible

Seven things you keep.

Use your existing knowledge.

Management agents, metaverse, connector space, run profiles, sync rules – same concepts, same object model, same way of working. If you run MIM Sync today, you already know Identity Director Sync.


The Console start page: your management agents, run states and last results. If this looks familiar, that’s the point.

Use all your management agents.

They all keep running on Identity Director Sync – the ones you wrote, the ones you bought, and the built-in ones for AD, AD LDS and SQL, which our own management agents replace in place: same connector space, same configuration, no reload. Nothing to rebuild.


A mixed fleet in one list: built-in agents, purchased connectors and the ones you wrote yourself — all running unchanged.

Use your existing MA and MV extensions.

Every line of extension code you wrote for MIM keeps running on Identity Director Sync – no recompilation, no rewrite, no test cycle. Years of provisioning logic, carried over as it is.

The Extensions tab: your own MA and MV extension DLLs, loaded and running — no recompilation.

Use your existing servers.

Identity Director Sync runs where MIM Sync runs today: on your Windows Server, on your Microsoft SQL Server, in your data centre. No cloud tenant, no new platform to approve, no data leaving the building. Cloud systems stay what they are – sources and targets, through management agents, on your side of the line.

Use your existing database queries.

The Identity Director Sync database uses the same table names as the MIM Sync database. Name it like your old one, and your reports, queries and monitoring scripts run unchanged.


Side by side in SQL Server Management Studio: the MIM Sync database and Identity Director Sync — same table names, so your queries and reports keep working.

Keep your joins.

Identity Director Sync installs from a backup of your MIM Sync database. Every object, every join, every state is where you left it – no initial load, no rejoin. What took you years to get right stays exactly as it is.

Keep your preview.

Ask a MIM admin what they would never give up, and the preview is on the list: pick an object, see what a sync would do to it before it does. Identity Director Sync has it – same idea, same place in your workflow. It just reads better.


The same object, previewed in MIM Sync and in Identity Director Sync: the same answer, easier to read.

But better

Seven things MIM never had.

Use the dashboard.

MIM tells you what happened when you go looking – run by run, in the Operations tab, on the server. Identity Director Sync tells you at a glance. One screen shows whether the engine is healthy, what is waiting to be imported or exported, and what has failed – with a click that takes you straight to the error. Below it, the last 24 hours of runs as a chart and the week in overview. You see the problem before anyone calls.


The dashboard: engine health, pending imports and exports, errors one click from the cause — and the last 24 hours of runs in one curve.

Use the built-in scheduler.

Build your schedules in the Identity Director Sync Console – a delta schedule with delta import and delta sync, a full schedule, a night schedule for HR and the management agents that run once a day. Colour-code them, drop them into the calendar with the mouse. No Task Scheduler, no PowerShell wrappers.


The built-in scheduler: delta, full and night schedules, colour-coded and arranged in the calendar with the mouse.

Use sync rules without a portal.

In MIM, sync rules are not part of the sync engine – they live in the Portal, which means SharePoint and MIM Service just to edit an attribute flow. In Identity Director Sync they are part of the engine: configured in the Sync Console, next to the management agents they belong to.


Sync rules live right next to the management agents they serve — no Portal required.

Use roles that live in Sync, not in AD.

In MIM, whoever controls the five sync security groups in Active Directory controls the sync engine. In Identity Director Sync, permissions are assigned inside the product – Admin, Operator, Viewer – stored in the Sync database and changed only by Sync admins, through the Console or the API. AD binding is available if you want it, but the decision is yours, not your AD admin’s.


Role management inside Sync: Admin, Operator and Viewer are assigned here — not inherited from AD groups.

Use a browser, not a remote desktop.

MIM Sync is run through the Synchronization Service Manager – a Windows application on the sync server itself. Every run check, every metaverse lookup, every change to a management agent means an RDP session to that server. Identity Director Sync puts all of it in a browser tab: configuration, management agents, sync rules, schedules, run history, metaverse and connector space search, preview. Nothing you do daily needs a desktop on the server. Your sync engine finally has a URL.


The Console in a browser tab — note the address bar. Configuration, runs and search without a single RDP session.

Use the API for everything.

Everything the Console does, the API does too – start a schedule, read a run result, change a management agent, search the metaverse. MIM Sync offers WMI for runs and little else; Identity Director Sync is scriptable end to end, from your pipeline, your monitoring or your own tooling.


One call, one answer: the same operation the Console performs, scripted from PowerShell.

Use codeless provisioning – without the Portal.

Codeless provisioning in Identity Director Sync works the way it works in MIM: declaratively, on top of sync rules – which object to create where, from which attributes, under which condition. The difference is where it lives. In MIM, that takes the Portal, SharePoint and MIM Service. In Identity Director Sync it is part of the engine, configured in the Sync Console. Your extensions keep running for everything beyond the standard cases.


Declarative provisioning, enabled directly on the sync rule — codeless, and without the Portal.

What’s next

Three dates.

Use the runway.

Extended support for MIM 2016 ends on 9 January 2029. Until then, Identity Director Sync runs your management agents and extensions in compatibility mode – unchanged, as you have them today. Before that date, they need an update to the Identity Director library. The standard management agents – ours and Microsoft’s – we take care of. What remains is what you built yourself, one management agent at a time, whenever it suits you. Start now, finish at your own pace.

Use Linux and PostgreSQL. On the roadmap: summer 2027.

Today, Identity Director Sync runs on Windows Server and Microsoft SQL Server. From summer 2027 at the earliest, it will also run on Linux and PostgreSQL – for installations that have completed the update to the Identity Director library, and for new installations from day one. A promise with a date, not a feature. Migration comes first.

Use plain language to configure Identity Director Sync.

Write what you need the way you would brief a colleague – “connect the new HR system, employee ID is the anchor, department has to reach AD and the phone system” – and Identity Director Sync turns it into configuration: the management agent, the metaverse schema, the extension, the target flow. You review, adjust, apply. It also reads your metaverse and suggests the reports you are missing. The model runs on your own infrastructure – no cloud, no data leaving the building. Coming before MIM support ends.

Synchronization, continued – on your configuration.