In most Entra ID migrations, technology is not the problem. After years of IAM projects at a wide range of organisations, I can say that with confidence. The technology behind Microsoft Entra ID is mature, well documented and in most cases reliable. Yet time and again I see migration projects overrun, fail to move forward or deliver a fraction of what they promised.
The cause almost always lies elsewhere: in governance, data quality and organisational decision-making. These are the five critical pitfalls I come across most often, and how you avoid them.
Pitfall 1: Nobody owns the identity data
Before you migrate a single account, you need to know whether the data you are migrating is actually correct. In most organisations the answer is: no, not really.
Accounts of employees who left long ago are still active. Groups were once created for a project that never went ahead. Roles have been copied over the years without anyone asking whether they are still right.
The technical migration does not deal with this. It moves what is there, including all the clutter.
What you need is a data owner: someone who takes responsibility for the quality of accounts, groups and roles before the migration starts. That is not a technical role but a business role. And that makes it difficult, because the business usually sees identity management as an IT problem.
Raise it early in the project. Otherwise you pay the price later.
Pitfall 2: The legacy applications nobody wants to touch
Every organisation has at least one: the application that has been running for ten years, that half of the critical processes depend on, and that nobody quite understands any more. No recent documentation. No active supplier. Sometimes not even an owner left within the organisation.
And that application depends on the identity system you want to replace.
Applications like this are often deliberately kept out of the scope of a migration, "we will deal with that later", but that moment rarely comes. They become a blocker that slows down the entire programme.
The approach: make an inventory of every application with an identity dependency before the migration starts. Not only the modern applications with clean APIs, but especially the old, unknown, forgotten systems. Categorise them by risk and plan them in explicitly, either as part of the migration or as a deliberate exception with a clear end date.
What you do not want is to discover halfway through that you have forgotten an application that three departments use every day.
Pitfall 3: No governance structure for decision-making
A migration brings dozens of decisions with it. Who gets which role? Which groups are migrated and which are retired? Who is allowed to approve conditional access policies? What is the policy for guest accounts?
If those decisions have no owner, they end up in an email thread. The thread gets forwarded. Input is requested from people who have no time for it. And the project comes to a standstill.
What works: set up a steering group before the kick-off, with a clear mandate. Decide for each category of decision who has the final say. Draw up a RACI that does not put five people on responsible for the same choice.
Governance sounds heavy. But the alternative is worse: a project that waits for weeks on a decision that could have been taken in five minutes.
Pitfall 4: HR and IT do not talk to each other
Joiner-mover-leaver processes are the backbone of every identity system. Someone joins and gets an account. Someone changes role and gets different entitlements. Someone leaves and the account is blocked.
Simple in theory. A nightmare in practice if HR and IT are not on the same page.
What I often see: HR works with its own system (or Excel), IT keeps its own records, and the synchronisation between the two is manual and inconsistent. Employees have sometimes been working for two weeks before their account is created. Former employees sometimes still have active access weeks after their last working day.
An Entra ID migration is the ideal moment to fix this, but then you have to involve HR early. Not as a supplier of information, but as a process partner. The quality of their data determines the quality of your identity environment.
Invest in the link between the HR system and Entra ID. Automate the triggers. And agree on who is responsible when something is not right.
Pitfall 5: Scope creep without control
"While we are at it, can we also...?"
That sentence is the most dangerous one in any migration project. And it is always spoken by someone with good intentions.
While we are at it, can we also include the MFA rollout? Can we also revise the conditional access policies? Can we also clean up that old on-premises Active Directory?
Each of those questions is legitimate. But if you take them all on while you are at it, you double the scope without adjusting the budget and the lead time.
The solution is not a hard no, it is a controlled yes. Keep a backlog of every scope extension that is put forward. Assess them per sprint or per quarter. Only take on what fits within the planning and the resources.
And be transparent: if something affects the delivery date, say so straight away. Not afterwards.
The common thread
Entra ID is a powerful platform. But it does not solve organisational problems, it makes them more visible.
The organisations that get the most out of their migration are not the ones with the biggest budget or the most experienced technical teams. They are the ones that take governance, data and communication seriously before the first line of code is written.
Working on an Entra ID programme? Or have you just completed one? I am curious which of these pitfalls you recognise most, or which one I have missed. Let me know.