How to Move a Lightroom Classic 2026 Catalog to a Remote Mac?

Move the catalog only after backing it up, and prepare its related files and original photos according to what the remote Mac needs to access. If the originals will stay somewhere the Mac cannot reach, solve that access problem before opening the project there.

Suitable: photographers moving a Windows Lightroom Classic project to a remote Mac for continued editing.
Also for freelance retouchers switching between local and remote work, and small teams handing off catalog-based projects.

Start with the project you need to move

A Lightroom Classic catalog is not the same thing as the photos it manages. The catalog stores information such as photo locations and editing or rating details; the original image files remain separate. Adobe explains this distinction in its Lightroom Classic catalog FAQ.

That distinction determines what needs to travel:

Catalog only: useful when the remote Mac needs to inspect the catalog, but it is not a complete editing handoff if the Mac cannot access the originals.
Catalog and originals: the safer choice when the remote Mac must open and edit the actual photos.
Catalog with another verified route to originals: possible when the originals remain in a location the Mac can reach. Verify that access from the remote environment before relying on it.

A catalog copy alone can appear to transfer the project while leaving every photo disconnected. Conversely, copying a large collection of originals may be unnecessary if the remote Mac can reliably access them in their existing location. Decide which case applies before choosing a transfer method.

For a Windows-to-Mac move, also check that the Lightroom Classic version and macOS environment are compatible. Adobe’s current Lightroom Classic system requirements are the reference for supported system requirements. Do not assume that a catalog transfer by itself resolves a software compatibility issue.

Windows-to-remote-Mac transfer: close, back up, and inventory

Before moving anything, close Lightroom Classic on the Windows computer. Working from a closed catalog copy reduces the chance of transferring a catalog while it is being changed. Keep the original project intact until the remote copy has passed its checks.

Adobe’s catalog backup instructions explain how to configure and create a catalog backup. Treat that backup as a recovery copy, not as proof that the originals have been included. Keep it separate from the working copy so a mistake during transfer does not leave the only usable catalog at risk.

For the project inventory, look for these items:

The catalog file, commonly ending in .lrcat.
The associated .lrcat-data file, especially when the project contains AI-related editing data.
Preview data, which may appear as a .lrdata package or folder beside the catalog. Include it when practical if retaining existing previews matters; do not confuse previews with original image files.
Any Smart Previews or other project files that the workflow depends on.
The original photos, stored separately in their existing folders.

Adobe’s catalog migration guidance describes moving a catalog and its related files. Use that guidance to check which files accompany the catalog in the current version. File names and locations are concrete inventory details: .lrcat, .lrcat-data, and preview data are not interchangeable, and none of them should be mistaken for the original image collection.

A useful handoff note records the catalog’s current location, the original-photo folder locations, which files were copied, and where each copy was placed. Keep the note in plain language. A teammate should be able to tell whether the transfer includes originals or only catalog-related files without guessing.

Remote editing: make the originals reachable

If the remote Mac must edit the actual photographs, the originals need to be available to Lightroom Classic in that environment. There are two broad approaches: prepare the originals as part of the project transfer, or use a separately verified storage route that the remote Mac can access.

Neither approach should be assumed to work until it has been tested. A storage service, mounted volume, browser upload, or remote file-transfer method has its own limits and permissions. Confirm that the chosen method can deliver the required folders and file types to the remote environment. We cannot infer the available storage, mounting, or transfer capabilities of a particular remote Mac service from Adobe’s catalog instructions.

Before transferring a large project, test with a copy containing a representative set of photos and the related catalog files. Open that copy on the remote Mac and confirm that Lightroom Classic can access the originals. If the test fails, resolve the transfer or storage issue before moving the full project.

This avoids several common costs and risks:

Unnecessary transfer: moving every original when the remote Mac only needs a small, defined selection.
Incomplete handoff: copying the catalog but not the originals or a working access route.
Unclear storage responsibility: leaving the team unsure which copy is authoritative after edits begin.
Unverified access: discovering only after setup that the remote environment cannot reach the folder or storage location.

For a temporary retouching job, a smaller, well-defined project copy may be easier to verify than an entire archive. For ongoing work, agree in advance where originals live, who may change them, and how updates return to the main archive.

When photos show as missing: relink instead of removing them

A catalog that opens with missing photos is different from a catalog that will not open. If Lightroom Classic opens but shows missing images, the catalog may still contain the photo records and editing information; the paths to the original files may simply no longer match their new locations.

First, find the originals in the remote Mac’s file system or in the storage location that was intended to remain accessible. Confirm that the files are actually present before changing Lightroom Classic. A changed Windows drive letter, folder structure, or destination path can explain why the catalog’s saved location no longer works.

Then use Lightroom Classic’s folder or individual-photo relinking options to point the catalog to the actual files. Adobe’s instructions for locating missing photos cover the relinking process. If an entire folder moved, check the folder location first. If only a small number of images are missing, locate a representative file and confirm that the remaining files resolve as expected.

Adobe also documents how to create and manage folders. That is useful when the project’s destination structure needs to be made clear before relinking. It does not mean the catalog can recreate missing originals. The actual photo files must still exist somewhere Lightroom Classic can access.

Do not remove missing-photo entries simply to clear warning indicators. That can hide the evidence needed to find the originals and may make a handoff harder to recover. If the catalog itself fails to open or behaves as though it is damaged, stop working on the only copy and follow Adobe’s catalog corruption troubleshooting guidance.

The .lrcat-data file deserves a specific check when a project contains AI-related edits. Include it in the migration inventory alongside the .lrcat catalog, and avoid assuming that a catalog file by itself preserves every part of the working state. Adobe’s catalog FAQ provides the official context for catalog-related files.

Do not treat that as a universal guarantee that every edit will render or behave identically after a move. The outcome can depend on the project’s files and software environment. Instead, test a working copy and inspect representative photos that use different kinds of edits, including any AI-related adjustments the project depends on.

Preview data is another separate item. Keeping it may preserve existing previews and avoid having to rebuild them immediately, but it is not a substitute for the original photo files. If the remote copy opens but an image cannot be edited as expected, check both the original-photo link and the relevant catalog-associated files before concluding that the edit record is gone.

This check is especially important in team handoffs. A catalog that opens is only one part of a successful transfer. The receiving editor should also be able to locate the original, see the expected edit state, and distinguish a missing original from a missing or outdated preview.

Handoff checklist: prove the project works before returning it

Use this checklist on a copy before moving a full project or returning edited work. Each item can be checked by the sender and recipient, so ownership of the originals and catalog changes stays clear.

[ ] Close Lightroom Classic on the source computer before preparing the transfer.
[ ] Create a separate catalog backup and keep the source project unchanged.
[ ] Identify the .lrcat file and check whether the project has an associated .lrcat-data file.
[ ] Decide whether preview data should accompany the catalog.
[ ] Record whether original photos are included or remain in a location the remote Mac can access.
[ ] Confirm the actual transfer or storage method works from the remote environment.
[ ] Open a working copy of the catalog on the remote Mac.
[ ] Open representative photos and verify that the originals are available.
[ ] Check existing edits, including representative AI-related edits if the project uses them.
[ ] If photos are missing, confirm the files’ real location and relink them rather than deleting catalog entries.
[ ] Agree which copy becomes authoritative after remote edits and how catalog and photo changes will be returned.

For a small studio, add a short handoff note stating who changes the catalog, who manages the originals, and how the returned files will be reconciled with the archive. Avoid having separate editors make uncoordinated changes to different copies and then trying to combine them by memory. A clear return process is as important as the initial transfer.

If the project passes these checks, the current workflow may be suitable for remote Mac editing. If the remote Mac cannot reach the originals, the catalog state cannot be verified, or the team cannot agree which copy is authoritative, pause the move and fix that part first.

A local Windows workflow may avoid remote access and file-transfer uncertainty, but it cannot run macOS-only software. Buying a Mac can provide a dedicated machine, but it adds hardware cost and is harder to justify for occasional work. A remote Mac can suit a temporary editing task, though it still depends on verified file access and a return plan; it is not the best fit for work that requires a local physical connection or uninterrupted access to a machine under your control. If a temporary environment is appropriate, check the actual remote access options and available plans before preparing the full catalog. We recommend testing with a backed-up project copy first, then moving the working project only after the catalog, originals, and edits are all confirmed.