One Identity Manager → Identity Manager On-Demand (IMOD)
End of support turns a One Identity Manager roadmap into a deadline — and deadline migrations skip the careful work. Every object can move to IMOD correctly and your people can still be locked out of Salesforce on Monday. EnterprizID names the business processes that must survive the move, migrates the estate, and proves each process works before you go live.
The move, honestly
Identity Manager On-Demand is One Identity Manager delivered as a managed cloud service: One Identity operates the platform, you consume it. That is a different operating model, not a hosting change — and the differences are where migrations get hurt.
With Identity Manager On-Demand, One Identity runs the platform — infrastructure, database, availability, patching, and upgrade cadence. You stop operating servers; you also stop deciding when upgrades land. Operational burden drops, and so does direct control over the environment. Anything your team does today that assumes you own the box needs a new answer.
Most One Identity Manager estates carry years of customization — custom scripts, modified processes and templates, schema extensions, logic whose author has long since left. All of it was possible because the environment was yours. In a managed service, each customization must be found, classified, and re-established within what the service supports — which is why the inventory comes before the plan.
The connectors tying Identity Manager to Salesforce, Workday, ServiceNow, SAP, and your on-premises directories do not disappear — but a cloud-hosted service reaches your systems differently than a server on your own network did. Confirm every integration against the target rather than assume it. The one-off workarounds are the ones that surprise you.
Almost no estate cuts over in a single motion. For a period, the existing environment and IMOD run side by side — joiners keep joining, leavers must keep losing access on time, and both environments must agree about who has what. Unplanned coexistence is where schedules and budgets die, so it gets engineered up front, not discovered.
None of this argues against the move — only against improvising it. The strategy is rarely the problem; the manual middle is: discovery done by hand, customizations classified from memory, integrations confirmed by hoping, a test plan written the week before cutover. Everything below removes that middle.
Two definitions of done
Every line in the left column can be true — verifiably, reconciled-to-the-row true — while every line in the right column fails.
Both columns describe the same weekend. Only one of them is what the business paid for.
Start here
The Migration Blueprint Assessment does two jobs before anything moves. It inventories your One Identity Manager estate — every customization, workflow, connector, and integration, rated for how it carries into IMOD — and it names the business processes that must come through intact, each with an owner and written acceptance criteria. The migration is measured against those criteria.
Scope a Blueprint AssessmentHow the work runs
The order is deliberate. The acceptance test exists before the cutover weekend — so “done” is defined while everyone can still afford to be honest about it.
The proof
Validates the processes the Blueprint named — onboarding, access requests and approvals, revocation, certification — in IMOD, against the Blueprint’s acceptance criteria, while the cutover can still be steered. It turns “migration complete” from a claim into a demonstrated result the process owners have signed.
Explore Ratify →The engine
Executes the move: expert-led discovery of what your One Identity Manager estate actually contains, automated conversion, encrypted transfer, and near-real-time replication that keeps both environments aligned through coexistence — every object verified against source.
Explore eMigrateSecure →Support timelines are set per version by One Identity, and they change — publish a date and it eventually goes stale. What matters is which version you run and where it sits in One Identity’s published support lifecycle. Bring your version to a conversation and an Identity Advisor will confirm the specifics against the current lifecycle before any planning starts.
No. Staying current on a supported on-premises release, moving to Identity Manager On-Demand, or changing platforms entirely are all legitimate answers — the right one depends on your estate, your customizations, and your operating model. IMOD preserves the most of your existing One Identity Manager investment: your data model, roles, and workflows carry forward rather than being rebuilt. The Blueprint Assessment is useful either way, because it inventories what you actually run — the input every one of those decisions needs.
Not the data. Moving and verifying objects is a solved engineering problem. The hard part is everything the data sits inside — the undocumented customizations, the workflows that encode how your business actually approves access, the integrations, the coexistence period — and failures there are the quiet kind that clean reconciliation reports never show.
Some carry over, some get re-implemented within what the managed service supports, and some should be retired — a migration is the one moment you can shed accumulated complexity cheaply. Which bucket each lands in varies with how your estate was built, so the Blueprint Assessment classifies each one before anything moves. The failure mode to avoid is classifying live, mid-cutover.
Everything the assessment produced. Whether you proceed or take the plan elsewhere, the estate inventory, the named business processes, and the acceptance criteria are yours — act on them with any partner you choose.
Your One Identity Manager version, your customizations, your timeline — and what the move to IMOD looks like from here.
