The short version. Lightroom keeps your develop settings in its catalogue. Before you leave, write them out to XMP sidecar files — one plain text file next to each photograph. Photo Developer reads Adobe's crs: vocabulary directly, so your global tone and colour work opens already applied. Local adjustments, healing, collections and virtual copies do not travel.
The trap: for DNG and JPEG, Lightroom writes the metadata inside the file rather than beside it. If your library is mostly DNG, the menu command alone will not be enough. There is a fix, and it is one line.
Before you cancel anything
Do this while you still have a working Lightroom. Accounts differ on exactly what a lapsed subscription leaves you — the catalogue file does not disappear, and reports suggest you can still browse what is in it — but developing and exporting are what stop. Writing your settings out is far easier done from a Lightroom that is still fully working than from one that isn't, so do it first and cancel afterwards.
In Lightroom Classic, select a batch in the Library module and use Metadata → Save Metadata to File (⌘S). Lightroom writes each photograph's develop settings, keywords, ratings and labels into an .xmp file sitting next to the original.
Work in batches rather than selecting the entire catalogue at once. It is slow, it is disk-bound, and a batch that fails halfway is easier to find than a run of eighty thousand that did.
You are aiming for one condition, and it is easy to verify: every photograph has a file beside it with the same name and a different extension. Once that is true, the catalogue has nothing in it that only it can tell you, and you can leave whenever you like.
The DNG and JPEG trap
Lightroom writes external .xmp sidecars for proprietary raw formats — ORF, CR2, CR3, NEF, ARW, RAF and the rest. For DNG and JPEG it does not. Those formats can hold XMP internally, so Lightroom writes the metadata into the file itself.
That is reasonable and it is also a problem, because Photo Developer looks for a sidecar next to the photograph — PICTURE.DNG → PICTURE.xmp — and does not go looking inside the file. A DNG library that has been faithfully saved out of Lightroom can still open with every slider at zero.
This caught me, and it was not a small edge case — close to half my own archive is DNG or JPEG. If you imported through Lightroom's DNG conversion at any point, or shot JPEG before you shot raw, this is probably most of your back catalogue.
The fix is exiftool, and one line. To extract the embedded packet from a single file:
exiftool -b -xmp PICTURE.DNG > PICTURE.xmpTo walk a whole tree and write a sidecar beside every DNG:
exiftool -ext dng -b -xmp -w %d%f.xmp -r .Change -ext dng to -ext jpg for JPEGs. Two things worth knowing about it:
- It does not overwrite an existing sidecar. Run it a second time and it reports that it created nothing, so it is safe on a folder where some files already have sidecars — it fills the gaps and leaves the rest alone. Worth confirming on a copy of a folder before you turn it loose on an archive.
- It copies rather than converts. What lands in the sidecar is the XMP packet Adobe already wrote, unchanged — you can see it in the file, which still carries Adobe's own toolkit stamp rather than exiftool's. Nothing is being reinterpreted at this stage. Checked against my own archive: a sidecar written during my migration and one extracted from the same DNG today came out byte for byte the same.
Run it after the Lightroom save rather than before, so that what is inside the DNGs is current when you copy it out.
What transfers
Photo Developer reads Adobe's crs: namespace directly rather than inventing a private vocabulary for values that already have names. From a Lightroom sidecar you get:
- Light — exposure, contrast, highlights, shadows, whites, blacks
- The parametric curve — highlights, lights, darks, shadows
- Colour — temperature, tint, vibrance, saturation
- HSL — all twenty-four fields, eight colours across hue, saturation and luminance
- Colour grading — the shadow, midtone and highlight wheels
- Black & white — the channel mix
- Detail — sharpening amount, radius, detail and masking; luminance and colour noise reduction
- Effects — post-crop vignette and its midpoint and feather, grain amount, size and roughness
- Crop and straighten — the crop box and its angle
- Lens corrections — whether profile correction, chromatic aberration removal and vignette removal were switched on
The rest of what the sidecar carries — keywords, ratings and labels, face regions, hierarchical subjects, GPS, drone flight data, another editor's private namespace — is left exactly where it was. Photo Developer edits its own properties in place and preserves the rest untouched, which is checked with exiftool rather than with its own code.
Some of it is not idle, either. Photo Developer has no use for a rating or a keyword, but Photo Archive and Photo Culler do, and they are reading the same file. Work that arrived from Lightroom can go on being used by whichever tool it suits — you are not choosing between opening a photograph here and keeping what Lightroom put in it.
What doesn't
This is where things stand today, and it is the half of the page most likely to age — what a sidecar carries and what an application chooses to read from it both move. Check it against the version you are running rather than trusting this list forever.
As of now, expect these not to arrive:
- Local adjustments and masks. Photo Developer has its own and keeps them in its own namespace. Lightroom's are not read.
- Healing and spot removal. Retouching does not come across — a frame you cleaned up will open with the spots still in it.
- Virtual copies. Nothing converts. Snapshots cover some of the same ground, but they are not the same idea and there is no translation between them.
- Collections and stacks. Your folders on disk are the library here.
- History and presets. The edit history and Lightroom's own preset format stay behind.
- Which lens profile Lightroom chose. Whether the corrections were switched on does come across; the identity of the profile does not.
A rough guide, if you want one: what you can see by opening the sidecar in a text editor has a chance of travelling, and what you could only see inside Lightroom does not. Retouched frames are where this costs you most, and that is worth knowing before you commit rather than after.
What it will look like
Recognisably your edit. Not pixel-identical to it, and you should be suspicious of any tool that claims otherwise.
Photo Developer develops through a different raw decode with a different tone response behind the sliders. A value of −10 on highlights meant something specific inside Lightroom's engine and means approximately that here. On most photographs the difference is small enough that you would not go looking for it. On a heavily pushed file — deep recovery, extreme white balance, a hard curve — you will see a shift.
What you should expect is a photograph that opens as the one you made, close enough that you are adjusting rather than starting over. That is the useful promise, and it is the one a sidecar can actually keep.
Checking it worked
Open a photograph you developed in Lightroom and look at the panel list down the right-hand side. Panels carrying settings are marked with a dot.
If Light, Curve, Color, HSL, Grade, Presence and Detail light up, the sidecar was read and your edits arrived. If everything is dark on a photograph you know you worked on, the sidecar either was not written or is not beside the file — check for the DNG case first, because that is the usual answer.
Tone EQ staying dark is not a fault. It is a Photo Developer control with no Lightroom equivalent, so nothing Lightroom wrote could switch it on.
One last piece of insurance, and it costs nothing: keep the catalogue file. It is small next to your photographs, and as long as it exists the option to go back exists too. Migrating is not the same as burning the boat.