The release-note copy says that projects from DaVinci Resolve 21.1.2 cannot be accessed by DaVinci Resolve 20.3.2. That version boundary makes the first step clear: back up the project library and each project separately, then test representative copies before opening production work in the newer version. A library that remains accessible does not prove every project can be rolled back. (Release-note copy)
Who should use this checklist: Windows-based editors who need a Mac environment to review Resolve projects; independent creators maintaining an older project library; and small teams that need to assign upgrade, review, and recovery responsibilities.
Last updated October 27, 2026. Version and backup details checked against the release-note copy, the official support download page, and the linked Resolve guides. Recheck those sources before acting if the release notes or version guidance have changed.
Check the project-library boundary before upgrading
A project library and an individual project are not interchangeable backups. The library is the container you use to organize and access projects. A DRP export is a separate copy of an individual project that you can import into a library. The DaVinci Resolve beginner guide’s library backup instructions and the editor guide’s DRP import and export instructions describe these distinct operations.
The distinction matters when you plan to return to an older version. The release-note copy explicitly distinguishes library access from project-version access, and states that projects from DaVinci Resolve 21.1.2 cannot be accessed by DaVinci Resolve 20.3.2. Do not turn that statement into a broader promise about every library, project, or migration path. Your own copies and restore test are the evidence for your workflow. (Release-note copy)
| What you are checking | What the backup or test covers | Decision |
|---|---|---|
| Project library | A separate library-level recovery copy | Keep it outside the library you intend to upgrade; confirm who can restore it. |
| Individual project | A DRP export you can identify and import separately | Export the representative project and verify the file is present before proceeding. |
| Older-version access | A restored copy opened in the older environment you intend to use | Treat it as unverified until the actual copy opens and its contents pass review. |
| New-version review | A disposable copy opened in DaVinci Resolve 21.1.2 | Use it to inspect the project without risking the production copy. |
Record what must be recoverable
Before upgrading, write down the exact recovery target. “We have a backup” is not enough if nobody knows which library copy is current, where the DRP export lives, or who is permitted to restore it. Your inventory should distinguish library backups from individual project exports.
Use a simple record for each project you need to protect:
- Library name and backup location: identify the library and the separate destination holding its backup.
- Project name and DRP location: record the exported file’s name and where the team can retrieve it.
- Version boundary: note the version used to create or last review the project. If a rollback depends on DaVinci Resolve 20.3.2, record that requirement and test it against the release-note boundary.
- Recovery owner: name the person responsible for locating the backup and restoring a copy.
- Acceptance owner: name who will compare the opened project with the approved reference and sign off on delivery.
Keep the names descriptive enough that a teammate can distinguish the production library, a backup, and an exported project without guessing. Avoid storing the only copy inside the library that is about to be changed. The purpose is not to create a large archive; it is to make the intended recovery path findable and testable.
Test the rollback path with copies
A backup is only useful for rollback if your team can restore it in the environment it needs. Test that route before the upgrade, not after a problem appears. Keep the official statement and your team’s result separate: the release-note copy defines the stated version boundary; your test tells you whether your specific backup and restore procedure works.
Follow this sequence:
- Choose a representative project. Pick a copy that includes the kinds of timelines, media, and effects your team regularly hands off. Do not use the only production copy.
- Export the individual project. Create a DRP file and confirm that it is stored outside the library being upgraded. The official editor guide explains project export and import.
- Back up the library separately. Confirm that the library backup exists in its intended recovery location. Do not count the DRP export as a replacement for it.
- Restore a test copy. Use your team’s documented procedure and the older-version environment required for rollback. Record whether the copy can be found, restored, and opened; do not infer success from a file being present.
- Record the result and owner. Note the version used, the copy tested, any missing steps, and who is responsible for repeating the recovery if needed.
If a restore test fails, stop before upgrading the production library. Find out whether the problem is the backup, permissions, the restore procedure, or the version boundary. A successful library restore alone does not establish that an individual project can be accessed by an older application version.
Review project contents against a known reference
Once the backup and recovery path are clear, review a disposable copy in the target version. Select a project that represents real work, not an empty test timeline. The aim is to identify changes that matter to your delivery, not to assume that a project opening without an error means it is approved.
Compare these elements with a reference from the existing workflow:
- Timeline structure: inspect the expected sequences, edit points, track layout, and any nested or compound elements relevant to the project.
- Media availability: check whether the clips resolve to the intended source files. Record missing or relinked media rather than treating a visible timeline as proof that every source is present.
- Color work: compare key shots and the scopes or correction decisions your team uses. The official colorist guide covers scopes, color correction, and delivery settings; use your approved project reference to decide whether the result is acceptable.
- Fusion or other critical effects: inspect the nodes or effects that are important to the project. The Resolve 21 feature guide can help you identify documented changes to investigate, but a feature guide is not a guarantee that every existing project will behave as expected.
A documented fix or change is a reason to check the affected part of your project. It is not evidence that every timeline, effect, or media path will be unaffected. Note the specific project copy and the specific elements reviewed. If an issue appears, preserve a screenshot or a short written reproduction, then compare the copy with the untouched source before making corrective edits.
Validate delivery separately from preview
An acceptable viewer preview is not the same as an accepted deliverable. Your client, editor, or receiving workstation may have different expectations for file format, audio, color, naming, or playback. Define those requirements before exporting the test copy.
| Acceptance area | What to verify | What counts as a pass |
|---|---|---|
| In-app review | Key timeline sections, media, and project-specific effects | The designated reviewer confirms the project matches the approved reference. |
| Export settings | Required format, resolution, frame rate, audio, and destination | Settings match the receiving team’s written delivery specification. |
| Exported file | File opens and plays in the intended receiving workflow | The recipient or a designated reviewer confirms that the delivered copy is usable. |
| Handoff record | Project copy, export, version, and review owner are identifiable | Another team member can tell which version was reviewed and which file was approved. |
The official colorist guide documents delivery settings, but your own delivery specification decides what passes. Do not record an export as accepted just because Resolve completed it or because it played in the application used to create it. If the recipient’s setup is part of the delivery requirement, include that recipient-side check in your approval record.
Decide whether remote Mac review fits the job
DaVinci Resolve is not restricted to Mac. A remote Mac is relevant here only if you need access to a Mac environment for project review or handoff checks. It does not prove a project is compatible with an older version, replace a tested backup, or certify the recipient’s workstation.
Before choosing that route, identify what you need to validate: access to the correct application version, a safe way to transfer the project copy, a way to retrieve a test export, and a reviewer who can compare the result with your reference. Confirm the service details directly before starting. The available site information for this article does not document a specific remote access or file-return workflow, so this guide does not claim one or describe an unverified process.
Use the remote environment only for the checks it can actually support. Keep project-library backup, DRP export, rollback, and final recipient acceptance as separate responsibilities. If you are comparing temporary access options, review the details on the MACCOME remote Mac page before deciding whether they match your project and handoff needs.
Scenario: You edit on Windows, maintain a project that may need to remain accessible in DaVinci Resolve 20.3.2, and want a Mac-side review of a copy. First export the DRP and back up the library. Then confirm the older-version restore route. Only after that should you open a disposable copy in the newer version, compare the timeline and effects, and ask the receiving team to verify the exported file. If you cannot complete those checks, do not treat the review as approval to upgrade the only copy.
Resolve upgrade FAQs
What should you back up before opening a project in DaVinci Resolve 21.1.2?
Keep a project-library backup and a separate export of each representative project, such as a DRP file. They protect different things: a library backup preserves the library-level recovery path, while an individual project export gives you a separate project copy to import and inspect. Store both outside the library you plan to upgrade, label them clearly, and confirm who can restore them.
Can a project opened in DaVinci Resolve 21.1.2 still be opened in 20.3.2?
The release-note copy linked above states that projects from DaVinci Resolve 21.1.2 cannot be accessed by DaVinci Resolve 20.3.2. Do not treat access to a project library as proof that every project inside it can move back to the older version. If you need a rollback route, test restoration and opening with copies before changing your production project.
Does project-library compatibility mean every project can be rolled back?
No. Library compatibility and individual project access are separate checks. A library may be accessible while a project saved or created in a newer version remains outside the older version’s supported access boundary. Preserve the library backup and individual DRP exports, then test the exact restore path and older-version environment your team would use.
How can you review a Resolve upgrade without owning a Mac?
You can consider a remote Mac as a temporary review environment, but first confirm that the service provides the access and file-transfer workflow your project requires. Upload a disposable project copy, review it against your acceptance criteria, and retrieve a test export. A remote session does not replace checks on the actual delivery workstation or with the recipient.
If you do not have a Mac available for a controlled review, renting one temporarily may be more appropriate than buying hardware for a single upgrade check. That option still has trade-offs: you must arrange project transfer, verify the service’s access and file-return process, and test the receiving workflow yourself. If you want to assess whether a temporary environment fits, compare the available details through MACCOME’s remote Mac options. Keep the upgrade blocked until your backups, recovery test, and delivery review are complete.