DaVinci Resolve Says Project Created With a Newer Version: Fix

Which version pairs actually trigger this error?

This isn't a one-time quirk from a single release. It's a pattern that repeats at nearly every major and point-release boundary, and knowing the shape of the pattern tells you whether you're looking at a quick upgrade or a real workaround job.

Notice the shape repeating in every row: the project library, the container holding your list of projects, tends to stay reachable across one version jump. The individual project inside it does not, the moment it's opened. The pattern has held across every major DaVinci Resolve release for years, which means it will almost certainly hold for whatever version ships after 21 too. Plan around it as a permanent feature of how Resolve works, not a bug some future update will quietly fix.

Point releases matter here too, not just major version numbers. Going from 21.0 to 21.0.2 is far less likely to touch the project schema than jumping from 20.3.2 to 21.0, but Blackmagic doesn't publish a guarantee either way for point releases, so treat any version difference as a potential trigger until you've confirmed otherwise on a copy of the project you can afford to lose.

Should you upgrade instead of downgrading?

Before you touch AAF exports or Media Management, ask the obvious question: can you just match the newer version instead of fighting it? This is the fix that costs you the least and preserves the most, and it's worth ruling out first every single time.

If the project was opened in DaVinci Resolve 21.0.2 and you're currently on 20.3.2, installing 21.0.2 on your machine solves the problem completely. Every grade, every Fusion comp, every Fairlight mix comes across intact, because you're no longer asking an old build to read a new format. This is free either way, since both the free and Studio editions of Resolve ship the same version numbers and the same download is available from Blackmagic's support and downloads page.

The two situations where upgrading isn't the answer:

1. You're locked to an older version for a specific reason. Maybe a third-party plugin you depend on hasn't been updated for the new build, maybe you're on hardware Blackmagic dropped support for, or maybe a facility-wide standard keeps every machine pinned to one version for the length of a production. In any of these cases, upgrading solves this one project and breaks something else.
2. You genuinely need to send the project backward, to a colleague, a client, or an older workstation that isn't yours to update. This is the real use case for everything covered in the rest of this page.

If neither applies to you, stop reading the workarounds and just install the current version. Upgrading your own Resolve build is the only fix on this page that doesn't cost you any data. Everything past this point is a workaround, not a repair, and workarounds always leave something behind.

How do you check what version created a project before you open it?

The single most avoidable version of this error is the one where you open a project blind, watch it fail, and only then realize you've now got to figure out the workaround under time pressure. Checking first costs you thirty seconds.

A .drp file, DaVinci Resolve's project export format, is actually a zip archive under the hood, and its version tag lives readable inside one of the internal XML files. A dedicated freeware utility exists specifically to read that tag without you having to unzip anything manually. Built for Windows and shared on the Blackmagic Forum, it lets you drop a .drp, .drt, or .dra file onto its icon and prints the exact Resolve version that exported it, as documented in that forum thread.

If you're on macOS, or you'd rather not run a third-party console tool at all, you can do the equivalent check by hand:

1. Make a copy of the .drp file, since you're about to rename and poke at it.
2. Rename the copy's extension from .drp to .zip.
3. Extract it with your OS's built-in archive tool.
4. Open the extracted Gallery.xml or project.xml file in a plain text editor and look for a version string near the top of the file.

This works because a .drp is fundamentally a structured zip, not a proprietary binary format, so any tool that opens zip archives can get you inside it.

Checking a project's version tag before you try to open it takes thirty seconds and can save you an afternoon of guessing. Do this any time a project arrives from someone else, from a different machine of your own, or from a backup you're not sure predates your last update. It's the cheapest diagnostic step on this entire page, and it's the one people skip most often, right before they end up here searching for this exact error.

How do you use Media Management to bring media and bins across?

If upgrading isn't an option and you need the folder structure your Media Pool had, not the grade, not the timeline edit itself, Media Management is the tool built for exactly this handoff. It doesn't move the project. It moves the media the project references, along with the organizational structure you built around it.

Run this from the newer version, the one that can still open the project:

1. Open the project in the newer build of Resolve, where it opens normally.
2. Go to File, then Media Management.
3. Point the operation at a destination folder with enough free space for your source media, since Media Management copies or transcodes files rather than just referencing them in place.
4. Let it run. This preserves the folder structure you built in the Media Pool, per Blackmagic's own documentation of the feature.
5. On the older machine, open a new, empty project.
6. Navigate to the folder Media Management created, select the top-level folders, right-click, and choose "Add to Mediapool (create bins)."

Riccardo Luppi walked through exactly this sequence on Creative COW when a user needed to move a Resolve 18 project's organization into Resolve 16 without the effects that wouldn't have survived the jump anyway: use Media Management to preserve the folder structure, then add those folders back on the older side, in that same forum thread.

What you get: your bin hierarchy, your source media, organized the way you left it. What you don't get: your timeline, your cuts, your grades, or your Fusion work. Media Management solves the "I don't want to re-import three hundred clips and rebuild my folder tree" problem specifically. It was never meant to solve the "I need my edit back" problem, which is what AAF and XML export are for.

How do you export AAF to move the edit itself?

AAF is the format built specifically for carrying an edit between different NLEs and different versions of the same one, and it's the more reliable of your two export options when audio matters, since Advanced Authoring Format was designed from the start to hold multi-track audio references alongside picture.

From the newer version of Resolve, the one that can currently open your project:

1. Select the timeline you need to move, either in the Edit page or from the Media Pool.
2. Go to File, then Export AAF, XML, or use the shortcut Shift-Command-O on Mac.
3. From the Format dropdown, choose AAF Files.
4. Name the export and pick a save location, then click Save.

What survives the trip depends heavily on which export path you take, and this is the detail most people miss. If your timeline was originally imported from an AAF and hasn't had major editorial changes since, Resolve can export "all audio and effects using data from the original AAF file that was exported" from wherever it originated, provided that original file is still sitting where Resolve expects it, per Blackmagic's manual on AAF export. If you right-click and choose Generate New AAF instead, which is what you'll do for a timeline built natively in Resolve, "audio and effects that are not supported in DaVinci Resolve in an AAF import are discarded" during that generation, per the same manual.

AAF was built to carry audio and cuts between editing systems, not to carry a color grade. That last row in the table is the one that trips people up, since it's easy to assume an export format that handles this much complexity handles everything. It doesn't, by design. Grades live in Resolve's node system, a structure specific to Resolve itself, and no interchange format, AAF included, was built to represent it.

How do you export XML instead, and when should you pick it over AAF?

XML is the lighter, simpler alternative, and it's the better choice specifically when your timeline is a picture-only cut with straightforward transitions and you don't need Resolve to reconstruct complex audio routing on the other end.

The export steps are nearly identical to AAF, since both live behind the same menu:

1. Select your timeline.
2. Go to File, then Export AAF, XML.
3. This time, choose XML instead of AAF Files from the Format dropdown.
4. Save it somewhere both the newer and older machine can reach, or somewhere you can transfer it easily.
5. On the older Resolve, create a new project and import the XML through File, then Import Timeline, then Import AAF, XML.

Pick between the two formats based on what your timeline actually needs to carry:

• Choose XML for a straightforward picture cut, simple cross-dissolves, and situations where audio can be re-conformed or isn't the priority.
• Choose AAF when audio has to survive intact, since it was purpose-built for that handoff in a way XML's original design never fully matched.
• Use both if you're not sure. Export each, import each into a test project on the older version, and compare which one reconstructed more of what you actually need before committing to a full rebuild.

Whichever you choose, expect the same limitation as AAF: the edit structure travels, the grade does not. XML and AAF are both edit-decision formats at heart, lists of in and out points, source references, and basic transform data, not a serialization of Resolve's color pipeline.

If your workflow runs the other direction too, moving edits between Resolve and Premiere Pro rather than between two Resolve versions, the failure modes are different enough to need their own page. Our guide to DaVinci Resolve XML import from Premiere Pro not working covers the conform, timecode, and nested-sequence problems specific to that cross-application handoff.

How do you get your color grade back after an AAF or XML export?

This is the part nobody wants to hear, but it's better to hear it clearly than to discover it after you've already sent a client the wrong file. Neither AAF nor XML carries your grade. If the look of the project matters as much as the cut, you have two real options, and they trade off speed against fidelity.

Option one: render before you export. In the newer version of Resolve, the one that still has your grade intact, render the graded timeline out to a high-quality intermediate codec, ProRes or DNxHR at a mezzanine bitrate. This bakes the grade into pixels permanently. The older version then works from graded footage directly, with no node tree to reconstruct, at the cost of losing the ability to make further grade adjustments on the older machine.

Option two: export Gallery stills as a manual reference. If you need the project to stay editable and graded-from-scratch on the older version, export still frames from your Gallery at key points in the timeline before you do anything else. Those images become your visual target. On the older Resolve, you rebuild the grade by eye, matching your new nodes against the reference stills rather than trying to import grade data that was never going to cross the version boundary anyway.

1. In the newer version, open the Color page and select representative frames across your timeline, ideally one per distinct lighting setup or scene.
2. Grab a still for each using the Gallery panel's grab-still function.
3. Export the entire Gallery album as image files, keeping them organized by timeline position or scene name.
4. Move those images alongside your AAF or XML export to the older machine.
5. Rebuild the grade in the older version's node tree, using the still images as your visual reference rather than a data source Resolve can import directly.

Neither option is fast. A color grade never survives an AAF or XML export, no matter which format you pick or how carefully you configure it. That's not a settings problem you can fix with a checkbox. It's a structural gap between what these interchange formats were designed to carry and what Resolve's node-based grading actually is, and the only paths across it are baking the grade into rendered pixels or rebuilding it by eye against a reference.

Does this depend on Free versus Studio, or just the version number?

It's worth ruling this out explicitly, because it's a natural question and the answer isn't obvious from the error message alone. This compatibility rule is tied entirely to the version number stamped on the build, not to which license tier you're running.

DaVinci Resolve Free and DaVinci Resolve Studio share the same core application and the same project database format at any given release. A project opened in Resolve Studio 21.0.2 hits the exact same wall in Resolve Free 20.3.2 that it would hit in Resolve Studio 20.3.2, because the schema that changed lives in the underlying database engine, not in whatever features your license unlocks. Switching between Free and Studio, or upgrading your license, has zero effect on whether this error appears.

Where license tier does matter is what you're able to do once you've worked around the error. AAF and XML export are available in both Free and Studio, so the workarounds in this guide work regardless of which license you're on. If you're deciding whether Studio's price is worth it for other reasons entirely, unrelated to this specific problem, that's a separate question our DaVinci Resolve Studio price guide covers on its own terms.

What if your whole team is on different Resolve versions?

Everything above assumes one project moving between two machines you control. Add a shared PostgreSQL database and a team of editors, and the same underlying rule turns into a much bigger problem, because one person's update can silently lock out everyone else.

Here's how it actually plays out. Your team shares a project library on a PostgreSQL server. One editor updates their local Resolve install, opens a shared project to check something, and closes it again without changing a single frame. That's enough. The project's data just upgraded to the newer schema, and every other editor on the team, still running the older version, now hits this exact error the next time they try to open that same project, through no action of their own.

This is why facilities that run shared databases enforce version discipline as a hard rule, not a suggestion. The fix once it's already happened is the same as everything covered above: export AAF or XML from whoever's machine has the newer version, rebuild on the older side, or get every machine upgraded to match. But the real fix is preventing it in the first place:

1. Pin every machine touching the shared database to the identical point release, not just the same major version number, since even a jump from 21.0 to 21.0.2 carries some risk.
2. Agree as a team on a single person, or a single scheduled window, who's allowed to trigger an upgrade, and don't let anyone update independently on a whim.
3. Before any planned upgrade, back up the shared database in full, and confirm every team member has exported a .drp copy of whatever they're actively working on.
4. Test the upgrade on one machine against a copy of the database first, never against the live shared library everyone depends on.

One editor updating their own machine can lock an entire shared project database for the rest of the team without anyone touching a setting. That's the version of this error that costs the most, because it isn't one person's afternoon, it's everyone's, and it happens fastest on teams that never wrote down a version policy in the first place.

Is this a Mac problem, a Windows problem, or both?

The underlying rule, forward-only schema migration, is identical on both platforms, since it lives in Resolve's application code and database engine rather than the operating system. What differs is the tooling and paths you'll use while working around it.

On Windows, the version-identifier utility covered earlier runs natively, and your Resolve Disk Database or PostgreSQL install lives under AppData\Roaming\Blackmagic Design\DaVinci Resolve. If you're maintaining two Resolve versions side by side on the same Windows machine for exactly this reason, keeping an older build around specifically to handle downgrade requests, be careful about install order and database paths, since a newer installer can affect the shared PostgreSQL service that both versions rely on.

On macOS, there's no native build of that Windows identifier tool, so the manual zip-inspection method covered earlier is your equivalent. Your database and preferences live under ~/Library/Application Support/Blackmagic Design/DaVinci Resolve. Apple Silicon Macs add one more wrinkle worth knowing about if you're troubleshooting a launch failure that looks similar to this error but isn't: Resolve 21 requires macOS 15 Sequoia or later and dropped Intel Mac support entirely, a platform incompatibility that can masquerade as a version problem even though no project database is actually involved, as covered in our project-won't-open guide.

What's the full decision path, from fastest to most involved?

If you'd rather work through this in order than jump to the section matching your exact situation, here's the sequence that costs you the least at each step, worked from fastest to most involved.

1. Check the project's version tag first, using the identifier tool on Windows or the manual zip inspection on Mac, so you know exactly what you're dealing with before you try anything.
2. Try upgrading your own Resolve to match, if nothing else is stopping you. This is the only option that preserves everything, and it costs nothing but download time.
3. If you must stay on the older version, decide what you actually need back: the edit structure, the media organization, or the grade, since each needs a different tool.
4. Run Media Management if the folder structure and source media are what matters most.
5. Export AAF if audio needs to survive the trip intact, using the original-file method if the timeline came from AAF originally, or Generate New AAF otherwise.
6. Export XML if it's a simple picture cut and AAF feels like overkill.
7. Render the graded output, or export Gallery stills for manual rebuilding, if the color grade itself has to make the trip in some form.
8. If you're on a shared team database, treat this as a policy problem, not just a technical one, and get everyone pinned to the same point release going forward.

Each step down this list costs more time than the one before it. Checking a version tag takes thirty seconds. Rebuilding a grade by eye against Gallery stills can take hours, depending on how complex the original work was. Work from the top and stop the moment you've got what you actually need.

How do you stop this from happening again?

Every fix on this page exists because a backup didn't. The version mismatch itself is unavoidable, Blackmagic isn't going to add backward compatibility to its database engine, but getting caught by it without a safety net is entirely optional.

1. Export a .drp copy of any project before you or anyone on your team updates Resolve. This takes seconds and gives you an untouched fallback that opens fine in your current version no matter what happens to the live copy afterward.
2. Back up your project database on a real schedule, using the Backup button next to your library in Project Manager, not just before upgrades but as routine practice.
3. If you're on a shared database, write down a version policy and actually enforce it, since the workgroup scenario covered above is entirely preventable with five minutes of team agreement.
4. Hold your Resolve version steady during an active deadline project. A mid-project upgrade converts your working files into a format your backup machine, your freelancer's laptop, or your client's review station can no longer open, right when you have the least time to deal with it.
5. Keep the old installer around, not just the new one. If you ever need to downgrade a machine to match an untouched older project, having last year's installer saved somewhere beats hunting for it in Blackmagic's download archive under time pressure.

A project you exported as .drp before upgrading is the fastest fix for this entire error, and it costs you nothing until the day you need it. That's the whole point of a backup: it's invisible right up until it's the only thing standing between you and a rebuilt grade from memory.

Verdict: match the version, or budget for a rebuild

"This project was created with a newer version" isn't a corrupted file, a stuck lock, or a database you need to repair. It's DaVinci Resolve refusing to guess at a format it's never seen, which is the correct, safe behavior even though it feels like the app is blocking you for no reason.

Your fastest fix is always checking whether you can simply match the version that touched the project. When you can't, AAF and XML export get your edit across the gap, Media Management gets your media and bin structure across separately, and rendering the graded output or rebuilding from Gallery stills is your only real path for the color work itself. None of that is instant, and none of it is a bug you can patch around. It's the cost of two Resolve versions no longer speaking the same database language.

If you're spending more time reading forum threads trying to figure out which of these five paths applies to your exact situation than you are actually fixing it, that's the gap TryUncle is built to close. TryUncle is an AI tutor for DaVinci Resolve on macOS - ask in plain words and Uncle points at the exact control on your screen, live, inside your own project rather than a screenshot from someone else's version. TryUncle is currently in founder pricing, and it runs on macOS only.

Check your project's version tag before you touch anything else. Then pick the one fix from this page that actually matches what you need back, and skip the four you don't.