What you can export from Microsoft Entra ID and what you cannot
If a renewal, a licensing change or a residency review means you need identity data out of Microsoft Entra ID, start with the user list. Admins can download it as a CSV from the Entra admin center under Users, All users, Download users, and the file carries core attributes such as userPrincipalName, displayName, mail, objectId, userType, jobTitle, department and accountEnabled. The preview bulk user download goes further: it exports the columns you chose in the user list view and adds 27 more attributes, including assigned licenses, employee ID, last sign-in dates, proxy addresses and on-premises identifiers. Confirm the current column list in the Microsoft Learn guide before you rely on it, because the preview feature can change.
The user list is the only part of the tenant that comes out as a simple file. App registrations, enterprise applications, groups, Conditional Access policies, authentication methods and credentials have no single bulk export that you can import into another identity provider. Treat each of them as a rebuild project. Record every application's protocol, redirect URIs, claims mappings and assigned users or groups, and note which Conditional Access rules apply to which apps. Passwords cannot leave the tenant in readable form, and MFA registrations must be re-enrolled on the new provider, so plan user communication and a cutover window for that step. Export the lists first, then write the inventory, because the inventory is what your migration team will actually work from.
Which Entra ID data exports, by method and format
This table compares the two Entra admin center user exports, the default Download users CSV and the preview bulk user download, along with what each one includes and who can run it. Read it to decide which export covers your migration inventory and which fields you will need to fill from other sources. Both methods produce CSV files, so the main difference is how many attributes you get.
| Export method | Format | Attributes included | Who can download |
|---|---|---|---|
| Download users (default CSV) | CSV | userPrincipalName, displayName, mail, objectId, userType, jobTitle, department, accountEnabled | Both admin and standard users can download user lists (Microsoft Learn) |
| Preview bulk user download, list view columns | CSV | The columns selected in the user list view, plus 27 added attributes such as assigned licenses, employee ID and last sign-in dates (Microsoft Learn) | Confirm the role requirements for the preview feature in the Microsoft Learn bulk download article |
| Preview bulk user download, on-premises identifiers | CSV | On-premises SAM account name, distinguished name and security identifier, plus proxy addresses (Microsoft Learn) | Confirm in your tenant, since these fields apply only to users synced from on-premises Active Directory |
| Groups, app registrations and policies | Not exported as a user list | Not included in either user download, so these must be inventoried separately and rebuilt in the target identity provider | Confirm the export options for each object type in your tenant before planning the rebuild |
Why the default user list is not a full backup
The default Download users CSV in the Entra admin center is a convenient directory snapshot, not a complete record of your tenant. It carries a fixed set of attributes, including userPrincipalName, displayName, mail, objectId, userType, jobTitle, department and accountEnabled. Anything outside that set is missing unless you use the preview bulk download and choose the columns deliberately. That preview adds further attributes such as assigned licenses, employeeId, last sign-in dates, proxy addresses and on-premises identifiers, but only for the columns you select in the user list view. Before you rely on any export, list the custom and extension attributes your applications read, and check each one against the file. Confirm with the Microsoft Learn bulk download guidance which attributes each download method returns for your tenant, since the set you see can differ from what another admin exports.
Some data cannot be exported at all. Password hashes and stored credentials stay inside Microsoft's service, so no CSV will let a new identity provider verify existing passwords. Registered MFA methods, passkeys and other authentication methods are also not part of the user list. In practice, every user on the new provider must re-enroll MFA and either set a new password or go through a controlled first-login process. Plan this as a user-facing change: a communication, a support queue, a set of helpdesk identity-verification steps and a cutover window in which both providers can still sign users in. Confirm with Microsoft documentation for your tenant exactly which authentication method data is retrievable through the admin center and Microsoft Graph, and record the answer in your migration plan.
Treat the export as one input to a documented inventory rather than the backup itself. Pair the user files with an export of the group memberships, app registrations, enterprise applications, redirect URIs, claim mappings and Conditional Access policies, each of which must be rebuilt by hand or through scripts on the new platform. Keep the exports under the same retention and access controls as the source data, because they contain personal data and directory structure. Ask your Microsoft account team or licensing contact which of these artifacts your license level allows you to export, and have your security and privacy owners confirm the storage location before the first download.
What does not export in bulk and how teams rebuild it
The user list export covers identities, not the configuration around them. Application registrations, groups, policies, authentication methods, credentials and logs each need a separate inventory and a rebuild plan on the target platform. Treat each card below as a line item in your migration runbook, with an owner and a verification step.
App registrations and enterprise SSO settings
Each app registration and enterprise application holds redirect URIs, token claim mappings, signing certificates and client secrets. None of these come out in the user CSV. Export what you can see in the Entra admin center for each app, record the redirect URIs and claim configuration, and check the expiry dates on certificates and secrets. Confirm with your own tenant which settings your admin role can read through Microsoft Graph before you rely on a script, and keep the output in version control. On the target, recreate each client with the same redirect URIs and claims, then test sign-in per application before cutover.
Groups and dynamic membership rules
The bulk download lists users, not the groups they belong to or the rules that populate dynamic groups. Export group names, types, owners and membership rules from the portal, and export membership lists separately for each group that grants application access or license assignment. Dynamic rules are the risk here: a rule that works in Entra ID has no direct equivalent on the target, so it must be rewritten as a mapper, a federated attribute or a scheduled sync. Verify membership counts on both sides before any user loses access.
Conditional Access policies
Conditional Access policies define which users, apps, locations and risk levels trigger MFA or block sign-in. They are not part of the user export and cannot be reproduced from the CSV. Document each policy in its own table with its scope, conditions, grant controls and report-only status, and note which ones depend on Entra ID P1 or P2 features. Rebuild the controls that have a target equivalent, and record the ones that do not, so security owners can accept the gap in writing before cutover.
MFA and authentication method registrations
Users register authentication methods such as the Microsoft Authenticator app, phone numbers, FIDO2 keys and passkeys in Entra ID, and those registrations do not move with the user list. Expect to re-enroll users on the target MFA service, unless your own tooling can migrate TOTP seeds or WebAuthn credentials under a documented process. Plan the enrollment window, the help desk script for lost devices, and the fallback for users who cannot complete enrollment on day one.
Passwords and password hashes
Entra ID does not export password hashes or plaintext passwords in the standard user list. Users will need either a password reset on the target, a federated sign-in that keeps authentication with Active Directory, or a controlled hash import if your vendor and your security team approve that path. Confirm the options with your identity architect, since a hash import changes the trust model. Record which approach applies to each user group so the help desk knows what to tell people.
Sign-in and audit logs
Sign-in and audit logs are retained for a limited period in Entra ID and are not part of the bulk user export. Before cutover, decide which records your auditors, incident responders and compliance evidence depend on, and export them through the portal or a log integration while the tenant still holds them. Confirm the retention period that applies to your license and tenant configuration. Store the exported logs in your own archive with access controls, and note the date range covered so reviewers know where the evidence begins.
Sequence for a complete Entra ID export
This sequence turns a loose collection of exports into a documented inventory of users, groups, applications and policies that an IT team can check against the tenant before any migration work starts. Each step produces a file or record and a check that confirms it is complete.
Inventory applications, policies and licenses
An administrator with access to the Entra admin center lists every enterprise application, app registration, Conditional Access policy and group-based license assignment in the tenant. Record the name, object ID, sign-in method (OIDC, SAML or password-based) and owner of each item in a spreadsheet kept outside the tenant. The step is done when the list accounts for every application that someone in the business can name, and the owners have confirmed it. Anything that appears in sign-in logs but not in the list is a gap to resolve before continuing.
Run the default user list CSV
From the Entra admin center, open Users, All users and select Download users. This produces a CSV with the default attributes, including userPrincipalName, displayName, mail, objectId, userType, jobTitle, department and accountEnabled. Save it with the export date in the file name. Check that the row count matches the user total shown in the tenant, and that objectId and userPrincipalName are populated for every row. Mismatched counts usually mean filtered views or guest accounts that need to be treated separately.
Run the preview bulk download with needed columns
Use the preview bulk user download from the same list view after choosing the columns you need. This export adds attributes such as assigned licenses, employee ID, last sign-in dates, proxy addresses, and on-premises SAM account name, distinguished name and security identifier for synced accounts. Confirm that the on-premises identifiers are present for users synchronized from Active Directory and blank for cloud-only accounts. Store this file separately, because it contains sign-in dates and directory identifiers that your security team will want to protect.
Record group and dynamic membership rules
Export or document each security group and Microsoft 365 group, along with its membership type. For dynamic groups, copy the membership rule text exactly, since the rule is what defines membership and cannot be inferred from a user list. Record group owners and any group used for application assignment or license assignment. The output is a group register with one row per group. Verify it by picking five dynamic groups at random and confirming that the member count in the admin center matches the result of applying the rule to your user CSV.
Document Conditional Access and authentication settings
Capture each Conditional Access policy with its assignments, conditions, grant controls and session controls, plus the authentication methods policy and any named locations. Screenshots or exported policy JSON both work, but the record must show the policy state (on, report-only or off). Note which policies depend on Entra ID P1 or P2 features. The check is a second reviewer walking through the register and confirming that every enabled policy has a documented equivalent or a documented reason it is being retired.
Export or document application settings
For each application in the inventory, record the redirect URIs, SAML entity ID and assertion consumer URLs, claims mapping, token configuration and the assigned users or groups. Where an application is registered in your tenant, the app registration manifest can be downloaded and stored. Applications published by third parties often hold their own configuration, so ask the vendor what they need to reconfigure. The step is complete when each application has a settings record and an owner has signed off on it.
Verify the export against the tenant
Compare the user CSV and the preview download on row count, objectId and userPrincipalName, and confirm that the two files agree on every user. Check that the group register and policy register reference only objects that appear in the exports. Store the final set in access-controlled storage with a checksum and a short index file that lists each artifact, its export date and the person who produced it. The sequence is finished when a reviewer can reproduce the counts from the files alone.
How to verify the export is complete before you rely on it
Treat verification as a reconciliation between two counts, not as a visual check of the file. Count the rows in the Download users CSV, then compare that number with the user total shown in the Entra admin center for the same tenant on the same day, and record the date and the account that ran the download. If you used the preview bulk download, compare the row count against the filtered user list you selected, because the preview output only contains the columns and scope you chose. Then check that the userPrincipalName and objectId values are unique, since duplicates or blanks point to a problem in the export or in the source data. Confirm the export covers guest and member accounts if your migration needs both, by filtering for userType values before and after the download.
Spot-check accounts that carry on-premises identifiers. For users synchronized from Active Directory, pick a sample that includes admins, service-style accounts, shared mailboxes and recently created users, and compare their onPremisesSamAccountName, onPremisesDistinguishedName and onPremisesSecurityIdentifier values with the directory they came from. These fields are the most likely to break a Keycloak user federation or LDAP mapping later, so a mismatch here matters more than a missing display name. Next, check how disabled accounts appear. The accountEnabled column tells you whether a user is blocked, and disabled users should be carried over as disabled or excluded on purpose, not imported as active by accident. Write down which rule you applied and why, so an auditor or a colleague can follow the decision.
Keep the export under access control from the moment it is created. The file holds personal data, including names, email addresses, job titles and directory identifiers, so store it in an encrypted location with restricted read access, set a retention date, and remove copies from downloads folders and shared drives once the import is confirmed. Before any cutover, load the data into a test target such as a non-production Keycloak realm, run sign-in with a representative set of test accounts, and confirm the imported counts match your reconciliation. Keep the test results with the export record. If the export supports a compliance record or a data-handling obligation, ask your own auditors or privacy team to confirm what evidence they expect and how long it must be kept, because that decision belongs to your organization and not to the export tool.
What to plan before the Entra ID contract ends
Exporting user lists is the easy part. The harder work is deciding what replaces each Entra ID service, in what order, and on what schedule. The cards below cover the decisions that shape the export, from licensing and sign-in to retention of configuration.
Map bundled and add-on licenses
Start by listing which Entra ID capabilities you use through Microsoft 365 plans and which you pay for separately, such as P1, P2 or governance add-ons. Confirm with your Microsoft account team exactly which features stop at the contract end date and which continue under the Microsoft 365 subscription. Features such as Conditional Access and identity protection often sit in different tiers, so check each one you rely on. Record the answers before you schedule any export.
Set the application cutover order
Rank every enterprise application by business impact, sign-in volume and dependency on other apps. Move low-risk internal tools first and identity-critical systems such as the admin portal or VPN last. For each app, record its protocol (OIDC, SAML or LDAP), its claims and its owner. This order determines which app registrations and groups you rebuild first and which exports you need to keep on hand for longer.
Decide how Microsoft 365 sign-in continues
Decide whether Microsoft 365 sign-in stays on Entra ID or moves to another identity provider. Keeping Microsoft 365 usually means Entra ID remains the sign-in authority for Microsoft clients, which changes what you can retire. If you federate the Microsoft 365 domain to another provider, confirm the immutable ID and provisioning requirements before any user list is migrated. Document the decision, because it limits how much of Entra ID you can actually shut down.
Plan app re-pointing and testing
Re-pointing an application means changing its redirect URIs, client secrets, signing certificates and attribute mappings in the new identity provider. Build a test matrix for each app that covers first sign-in, password reset, MFA enrollment, group-based access and logout. Run tests with a pilot group before any production switch. Keep the old Entra ID registration intact until each app has passed its tests, so you can roll back quickly.
Schedule exports close to cutover
A user list export is a point-in-time snapshot. Export the standard CSV for basic identity records, and use the preview download with customized columns when you also need on-premises identifiers, last sign-in dates or license assignments. Repeat the export shortly before each cutover wave, because accounts change daily. Compare each new export with the previous one to catch joiners, leavers and disabled accounts that would otherwise be missed.
Retain configuration copies under policy
Export and store app registrations, groups, Conditional Access policies and enterprise application settings before the contract ends, because a user list does not carry them. Store the copies under your retention policy, with restricted access, and note who approved their deletion. Ask your legal and compliance teams how long audit logs and configuration records must be kept after the tenant is closed. Treat these copies as sensitive, since they describe your access model.
Questions teams ask before exporting from Entra ID
How much effort does a full export from Entra ID take?
The effort depends less on the user count than on how much configuration sits around the users. The CSV download of the user list is a quick task for one admin. The work that takes time is rebuilding what the export does not carry: app registrations, enterprise applications, groups, Conditional Access policies and the claim mappings each app relies on. Each application needs its redirect URIs, client secrets or certificates, SAML signing settings and attribute mappings checked and recreated in the new identity provider. Drivers that push effort up include the number of connected apps, custom attributes that downstream systems read, group-based assignments, and how many policies enforce different rules for different users. Ask any provider for a written inventory of apps and policies before quoting, because that inventory sets the scope.
Can an internal admin run the export without outside help?
Yes, for the data extraction itself. Admins can download the user list from the Entra admin center, and the preview bulk download can add more columns, including on-premises identifiers such as the SAM account name, distinguished name and security identifier. Both admin and standard users can download user lists, so access control on that download matters. The harder part is the rebuild. Most teams need identity engineers who understand OIDC and SAML, app owners who can test sign-in, and someone who can review what the export leaves out. Internal staff can own the inventory and the testing, while outside help usually focuses on the migration design, the rebuild and the cutover plan. Confirm the skills in your own team before deciding who does what.
What does outside help typically cover in an export project?
Outside help usually covers the parts that need repeatable engineering and written evidence. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source identity platforms in the client's own infrastructure. In an export project, that can mean designing the target realm or tenant structure, rebuilding clients and mappings, scripting user imports, testing each application and documenting the cutover and rollback. Most engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications.
Can passwords be exported from Entra ID to a new identity provider?
The standard user list does not carry password hashes, so passwords cannot be moved through the normal CSV export. Teams usually plan for users to set new credentials or sign in through a federated or brokered path during the transition. Some identity platforms can import hashes from other systems, but Microsoft does not offer a self-service export of password hashes in the documented download, and you should confirm the current position with Microsoft support before you plan around it. Ask your target platform which hash formats it supports and whether a password reset flow is needed for every user. Plan the communication and help desk load for that reset, since it is often the most visible part of the cutover.
How should MFA be handled when users move to a new provider?
MFA registrations are tied to the identity provider that stored them, so they do not transfer with the user list. Each user will normally need to enroll again on the new platform, and the methods offered must match your policy. Keycloak and authentik include MFA options, while teams that need more methods often add a dedicated MFA service. Decide before cutover which methods you will accept, how users verify identity during re-enrollment, and whether the help desk can reset factors. Avoid a process where a single phone call can reset MFA without checks, because that becomes an attack path. Test the enrollment and recovery flows with a pilot group first, and confirm each method against your security policy.
What does the business need to provide for the export?
The business has to supply decisions and people, not only access. The main inputs are a named owner for each connected application, someone who can test sign-in with real user accounts, and a sign-off authority for cutover and rollback. Application owners must confirm which claims, groups and roles each app depends on, because the export does not describe those dependencies. Leadership should approve the scope, the timeline and the handling of users who cannot move on the planned date. Compliance or security teams should review how the exported files are stored and deleted, since they contain personal data. Ask your provider to list these roles in the statement of work so that responsibilities are written down before work starts.
How do export costs change with the size of the environment?
Costs follow the components that have to be rebuilt, and each one has a different payer. Internal staff time covers inventory, testing and decisions. Engineering time covers rebuilding applications, policies and groups in the target platform. Infrastructure covers the servers, database and backups that run the new identity service, which recur after launch. Support and upgrades are often a retainer that recurs. One-time costs include the migration design, script development and cutover testing. Costs rise with the number of applications, custom attributes, Conditional Access rules and the number of environments such as test and production. Ask for a quote that lists each component separately, states what is one-time and what recurs, and names the assumptions about app count and policy count.
How DeployOpen works on this
DeployOpen starts an Entra ID exit by inventorying what the tenant holds beyond the user list, including app registrations, groups and policies that must be rebuilt in the target platform. The work is planned, implemented and documented inside your own infrastructure, with the scope agreed in writing before any work starts.
How we scope
- Inventory which Entra ID exports you need: the standard user CSV, the preview download with chosen columns, and on-premises identifiers.
- Map app registrations, groups, Conditional Access policies and licensed services that must be rebuilt rather than copied.
- Agree the scope, deliverables and timeline in writing; engagements are fixed-scope, and the quote follows from that scope.
How we build
- Set up the target identity platform in your cloud account, data center or air-gapped network, with the export files held there.
- Test each export on a copy of the data, checking attribute coverage against the columns your applications actually use.
- Rebuild applications, groups and policies in the target and verify sign-in for each application before cutover.
How we hand over
- Deliver documentation of the export procedure, attribute mapping, rebuilt configuration and the decisions taken during the work.
- Provide a record of which data was exported, where it is stored, who holds access and when it should be deleted.
- Walk your administrators through the target platform so they can run exports and changes without outside help.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Support can cover platform upgrades, backup and restore checks, and re-running exports if a directory changes.
- Confirm with DeployOpen during scoping which items, such as compliance evidence, fall inside the written scope and which need separate agreement.
