You have a .mde or .accde file. You need to migrate it — either to a modern format or off Windows 10 before EOL. You open the Access help docs, search online, and hit the same wall everywhere: "you need the original source database to convert."
If you don't have it, that answer feels like a dead end. It's not — but your options are different depending on what you're trying to preserve. This guide explains what .mde and .accde files actually are, why they can't be directly converted, and what your real migration paths look like.
A .mde file is a compiled, locked version of an .mdb database. When a developer creates a .mde, Access compiles all the VBA code into compiled bytecode and strips out the original source. Forms and reports are locked against design changes. The intent was software distribution — you could ship a working Access application to a client without exposing the source code.
An .accde file is the same concept for .accdb databases (Access 2007+). Same result: compiled code, design-locked objects, no editable VBA.
| Format | Source format | VBA source included? | Forms editable? |
|---|---|---|---|
| .mde | .mdb (Access 97–2003) | No | No |
| .accde | .accdb (Access 2007+) | No | No |
| .mdb | — | Yes | Yes |
| .accdb | — | Yes | Yes |
The key point: the VBA source code was discarded when the .mde was created. Microsoft Access has no decompile function. No third-party tool reliably reconstructs VBA from compiled bytecode. This is not a limitation of tools — it's how compilation works.
Avoid decompile utilities. Several tools claim to decompile .mde files. They produce garbage output — garbled variable names, reconstructed control flow that doesn't match the original, missing constants. The result looks like code but won't run correctly. You cannot trust migrated logic from a decompiled .mde.
The good news: the data is fully accessible. The tables inside a .mde or .accde file work exactly like tables in any other Access database. You can open them, query them, export them, and link to them from other databases.
What you lose access to:
This matters for migration strategy. If you only need to preserve the data, a .mde or .accde is not a problem. If you need to preserve the application — the forms, automation, business logic — you have a harder path.
LegacyLeaps scans your Access files and tells you exactly what's inside — table counts, form counts, VBA presence, and migration complexity — before you commit to any approach.
Try the Free ScanThis is always the right first step. Search thoroughly before assuming the source is gone:
If you find the source .mdb, the migration path is straightforward: convert MDB to ACCDB using LegacyLeaps (which preserves VBA, forms, and Jet SQL), then distribute a new .accde if needed.
If the source is truly gone and you only need to preserve data — not forms or automation — you can migrate the data layer cleanly:
This approach works well when the .mde was primarily a data store and the business logic was simple or has been superseded. It's not viable when the forms and automation are the core value of the application.
If the application logic is critical and the source is gone, rebuilding is the only reliable option. This means:
This is expensive if the application is complex. A done-for-you engagement with LegacyLeaps includes assessment of whether rebuilding is warranted versus migrating available components — we won't recommend a rebuild if data-only migration covers your actual needs.
If you need more time, a .mde that runs on .mdb (Access 97–2003 format) can be opened in modern Access on Windows 11 — the Jet engine still ships with Access for backwards compatibility. This is not a long-term solution, but it buys time while you locate the source or plan a rebuild.
Note: a .mde compiled for 32-bit Access will not run on a 64-bit Access installation. If you've upgraded Office to 64-bit, this may already be a problem.
The October 2025 Windows 10 end-of-life date creates urgency, but it doesn't change the technical constraints above. A .mde that runs today on Windows 10 will likely still run on Windows 11 — the compatibility issues are with the Jet engine, 32-bit/64-bit conflicts, and specific Windows 11 build changes, not with EOL itself.
If your .mde currently works on Windows 11, the EOL transition is not an immediate crisis for that specific file. The longer-term problem is that as Windows 11 updates roll out, Jet compatibility becomes less predictable. The right answer is still to find the source and migrate — EOL just increases the urgency of starting that search.
No. A .mde file has the VBA source code removed during compilation. Microsoft Access provides no decompile function, and no third-party utility reliably reconstructs the original VBA. The data tables are accessible, but the application logic cannot be recovered from the compiled file.
.mde is the compiled version of an .mdb database (Access 2003 and earlier). .accde is the compiled version of an .accdb database (Access 2007 and later). Both strip editable VBA and lock design. The underlying issue for migration is the same for both formats.
Yes. The data tables in .mde and .accde files are fully accessible. You can export tables to Excel, link them into a new database, or migrate them to SQL Server. The application layer — forms, reports, and VBA automation — cannot be migrated without the source.
Start by searching for the original .mdb source in backups, email archives, and with the original developer. If the source is unavailable, assess whether you need the application layer or only the data. Data-only migration is straightforward. Full application migration without source requires a rebuild.
LegacyLeaps offers free file scans and done-for-you consultations. We'll assess what you have, what's recoverable, and what migration actually costs — before you commit to anything.
Get a Free ConsultationPractical fixes for legacy Excel and Access problems. No spam.