Recreating User Accounts and Permissions After a QuickBooks Desktop Downgrade

User credentials created in the newer version do not survive a downgrade — this playbook covers exporting roles, re-provisioning accounts, and verifying access.

When a QuickBooks Desktop company file is downgraded to an earlier version or a different edition, the user accounts and permission sets created in the source file are not retained. The converted file opens with only the default Admin account active. Our engineers treat user re-provisioning as a discrete phase of every downgrade project: if it is skipped or done from memory, users end up with either too much access or not enough, and the first month-end close after conversion becomes a troubleshooting exercise. This playbook documents the full sequence — pre-downgrade export, conversion, and post-conversion re-creation — so the restored file matches the original permission structure.

Phase 1: Pre-Downgrade User Export

Before the source file leaves the workstation, document every active user account and the role assigned to each one. Open the source file in single-user mode as the Admin. From the menu bar, select Company > Set Up Users and Roles. For each user listed, record the username, the assigned role, and whether the account is currently active. If the file uses custom roles rather than the built-in defaults, note each custom role name and the specific areas of access it grants — window-by-window if any role has selective restrictions.

The most reliable capture method is a screenshot of each user's properties dialog alongside a spreadsheet that lists username, role, full name, email address, and license seat type. Store this export in a location separate from the company file itself. This becomes the single source of truth for re-provisioning; without it, the re-creation is done from memory and will not match.

Phase 2: Confirm the Admin Password

The Admin credential on the source file must be available to the engineer performing the conversion. If the Admin password differs from the one previously submitted for this file, provide the current password with the backup. The converted file inherits the Admin password from the source, so the same credential opens the downgraded file on the other side. Confirm this before the conversion begins — a locked Admin account on the downgraded file blocks every subsequent step in this playbook.

Phase 3: Post-Conversion Verification

Once the file is converted and opens cleanly in the target version, run File > Utilities > Verify Data in single-user mode before creating any user accounts. A clean Verify confirms the structural integrity of the downgraded file; if Verify reports errors, run Rebuild Data and re-verify. Do not proceed to user provisioning on a file that has not passed Verify — permission problems on a damaged file are difficult to distinguish from conversion artifacts. At this stage the file should contain only the Admin account.

Phase 4: Re-Create User Accounts

With the file open as Admin in single-user mode, return to Company > Set Up Users and Roles. Working from the spreadsheet captured in Phase 1, create each user account in the same order. Enter the username exactly as it appeared in the source file — matching capitalization and spacing — so that audit-trail entries and previous login history remain readable. Assign the corresponding role from the dropdown. If the source file used custom roles, recreate each custom role first under the Roles tab, then assign users to those roles.

For each account, set the password and confirm whether the user will be required to change it on first login. Mark the account active. Repeat until every user from the Phase 1 export has an entry in the downgraded file.

Phase 5: Access Validation

After all accounts are created, have each user log in at a workstation running the target version. Confirm that each user can access the areas their role permits and is blocked from areas it does not. Pay particular attention to sensitive areas — banking and credit card registers, payroll, and the Chart of Accounts — where an incorrect role assignment is most consequential. Have a user with a restricted role attempt to open a restricted report to confirm the permission boundary holds.

Rollback Points

Two rollback points exist in this workflow. The first is before Phase 4: if the converted file fails Verify in Phase 3, stop and address the file health issue before provisioning users. The second is during Phase 5: if a user's access does not match the documented role, delete and recreate that account rather than editing permissions incrementally — incremental edits on a fresh account can mask a deeper role-assignment error.

Clean Outcome

A completed re-provisioning produces a downgraded file where every user from the source file can log in with their original username, access exactly the areas their documented role permits, and open the file in multi-user mode without license or permission errors. The Phase 1 spreadsheet should have a one-to-one match with the user list in the downgraded file.