When Ratings, Keywords and Metadata Don’t Transfer Correctly

Treat compatibility as a handoff you can accept

A metadata migration succeeds when the information you need remains attached to the correct photographs, with its meaning intact, in the application that must use it. Opening every image is necessary, but it is only the first check. A five-star thumbnail can conceal missing captions, flattened keyword paths or a client collection that never left the previous database.

This article builds a practical acceptance exercise for a studio changing software or sharing work with another editor. It complements our EXIF, IPTC and XMP field guide, which explains the vocabularies. Here the question is operational: what should a small sample prove before you entrust an entire archive to a new arrangement?

Begin with the next task. An assistant preparing an album needs a reliable list of chosen photographs. An agency may also require usable captions and creator information. A historical archive may need old custom fields even if the new program cannot edit them. These are different acceptance conditions. Write them down before comparing colorful panels or counting fields in a product description.

Separate the value, its container and its behavior

EXIF commonly carries capture information; IPTC defines photographic descriptive and administrative properties; XMP provides a framework in which metadata properties can be expressed. A sidecar stores information outside the photograph, while embedded metadata resides within a supported image file. A catalog can retain another record again. They are related layers, rather than competing answers to a single question.

The IPTC mapping guidance explains that equivalent properties may require value conversion or combining fields. Its notes on dates, contributors and identifiers are useful when a superficially matching field has different structure. Consult the particular property instead of assuming every box with the same label is interchangeable.

Use three columns in your acceptance record: what the information means, where it is stored, and what the receiver can do with it. “Family group” could be a keyword in a file, a collection name in a database or a client list title in a gallery. All three can be valuable. Their similar wording does not make them equivalent data or guarantee an automatic conversion.

A synthetic studio agreement before testing, not a product compatibility matrix

Information	Required meaning	Acceptance question
Rating	The photographer’s current editing priority	Does the exact selected value reach the receiver without changing the original decision?
Color label	A named studio task, such as Needs retouch	Is the label’s meaning understood, even if the displayed color differs?
Keywords	Searchable subjects and, where required, their hierarchy	Can the intended photograph be found without merging distinct categories?
Collection membership	A photograph belongs to Album shortlist and Print candidates	Are both memberships preserved or separately documented?
Caption and creator	The intended description and attribution	Are punctuation, accents and separate fields retained correctly?
Edit instructions	A particular crop or processing interpretation	Can the receiver reproduce the edit, or is a reference render needed?

Build a twelve-photograph sample that can expose failures

Twelve is a manageable teaching example, not a statistically sufficient camera-certification suite. Use copies of ordinary, non-sensitive photographs and make the packet deliberately varied. Include the actual formats you need: for example, a proprietary RAW with its associated files, an ordinary JPEG, a TIFF and a supported editable document. Exclude any format you do not use rather than adding it merely to make the test look comprehensive.

Choose two photographs that originally shared a camera filename, now distinguished by job or camera identity. Add a portrait orientation, one photograph with a known time-zone context and one with no descriptive fields. Include an image used in two collections and a pair with related keywords under different parents. Put a conspicuous synthetic caption on another, including an accent, an apostrophe and a line break.

Record each expected result before migration. A useful row is: Harbor_A_0042, caption “Practice portrait — café doorway,” three stars, label “Needs retouch,” member of both “Album shortlist” and “Print candidates.” These invented values make errors visible. The expected record should live outside the application being evaluated so that a missing field does not erase the evidence needed to notice it.

Preserve an untouched sample packet and a separate working copy. Record application versions, operating systems and the transfer route. “Copied the folder” and “exported selected originals with metadata” are different procedures and should have different records. Do not repair the receiver manually before recording what arrived; otherwise you are testing your repair work rather than the handoff.

Name one writer for each field during the exchange

Two applications can each display a plausible value while reading different sources. A catalog might hold yesterday’s rating, a sidecar today’s rating and embedded information an earlier value. If both programs write automatically, merely opening the packet can introduce a new change. First identify the intended owner and the writer’s documented save behavior.

For a controlled exercise, close the receiving application, make one recognizable change in the writer, perform its normal save operation, then close it normally. Copy the complete associated packet to an independent test location. Open that copy in the receiver and record what appears. Change only one variable at a time: the save setting, the export option or the receiving preference.

Adobe’s current sidecar instructions note that Lightroom Classic 15 can maintain an additional ACR sidecar for substantial edits. An XMP-only copying assumption therefore needs review. Keep the actual associated-file family rather than treating a familiar suffix as a complete preservation inventory.

A timestamp alone cannot decide which value is correct. File copying, synchronization and later writes can change dates without explaining who approved the decision. Keep a short transaction note: which program changed which field, when the save completed and which packet the recipient opened. This is especially useful when the files travel by cloud sync rather than a single deliberate copy.

1. DeclareExpected values, meanings, memberships and required uses
2. WriteOne authorized writer saves the intended associated packet
3. ReceiveA separate copy opens in the documented destination
4. CompareCheck values, search behavior and reopen durability
5. DecideAccept, map explicitly, retain externally or stop

Test ratings and labels as decisions, not colored decorations

A rating should retain its numerical meaning and the photograph it describes. Test an unrated image as well as an assigned rating. Include a rejected photograph only if rejection is part of the actual workflow, and check whether it remains distinct from a low rating. Never infer delete permission from a visual reject mark during a migration exercise.

Adobe’s XMP Basic definitions distinguish numeric ratings from textual labels. A receiving program’s red square is consequently insufficient evidence that a studio task survived. Write down the text and intended action, then inspect how the new program represents or maps them. Preserve the old vocabulary even when choosing a simpler new one.

Imagine that red formerly meant “Requires skin cleanup” but means “Reject” in the new studio preset. A direct color match would reverse the instruction. A safe mapping could retain the old phrase as migration information and apply a separately agreed task label after review. Mark that as a deliberate translation, with a count and a reversible record, rather than claiming perfect transfer.

Test the decision where it will be used. Apply the receiver’s filter or search for the intended candidates, then compare the actual identities with the expected list. Adobe’s current Smart Collection criteria distinguish label text, label color, rating and pick state. Comparable controls elsewhere still require their own check; an imported display and a working selection query are different outcomes.

Check hierarchy, repetition and missing values separately

Use a hypothetical keyword path such as People → Family → Morgan, alongside Locations → Morgan. A flat list containing “People,” “Family,” “Locations” and “Morgan” may retain useful words while losing which parent belongs to which child. If the archive depends on that distinction, finding the word Morgan is not a passing result.

Test repeated terms, accents, an empty field and a deliberately removed keyword. An application can successfully add information yet fail to communicate deletion. A stale sidecar may resurrect a term that was removed in the catalog. Compare the after-state as a whole instead of checking only that the newest word appears somewhere.

Separate a keyword vocabulary from its assignments. The old program may store a reusable hierarchy that includes terms never assigned to a photograph. A photograph-level export might carry assignments without transporting the entire vocabulary. Decide whether you need that unused vocabulary for future work, and preserve it through the source program’s documented route or an external reference.

Collections and custom fields need their own migration plan

A collection usually describes an organizational relationship: one photograph may be in several groups without being copied. A database can also retain collection order, grouping rules, saved searches and human explanations. File metadata alone should not be assumed to reproduce those structures. Inventory them independently before the original program becomes unavailable.

For the twelve-image sample, create “Album shortlist” with four members and “Print candidates” with three, sharing two photographs. Record membership by stable image identity and preserve the chosen order if it matters. The union contains five distinct images; the summed membership count is seven. Both counts are correct, but they answer different questions. This small arithmetic catches accidental duplication or flattened groups.

For application-specific fields, choose between a verified native mapping, a read-only preservation field and an external record. “Archived but not searchable” may be an acceptable historical result if clearly documented. It is a failure when the next job requires searching that field every day. A migration plan should distinguish those outcomes without declaring every limitation catastrophic.

Resolve mismatches without overwriting the evidence

Suppose the receiving application displays the three-star rating correctly but has no caption. First inspect the exact copied packet and save settings. Was the caption ever written outside the old catalog? Is the sidecar next to the intended original? Was an export configured to omit descriptive information? Did the new program read a cached state? These questions isolate a missing transport step from an unsupported property.

If the caption appears in one panel but not search, record that distinction. If punctuation changes, keep both original and received values. If a date shifts, retain the displayed date, offset and intended event context before correcting it. Avoid a bulk “synchronize everything” operation while the authority of the competing values is unresolved.

Use a loss ledger with four outcomes: exact, translated, retained externally, or missing. Add an action owner and whether the result blocks the next task. A lost optional label color might be recoverable through a written mapping; a wrong identity for a selected print is a release blocker. Prioritizing by consequence prevents superficial differences from distracting from the dangerous ones.

A successful import is only half the acceptance exercise

Close and reopen the receiver, then repeat the important searches and membership checks. Work from the independent packet without an unnoticed connection to the old machine. If a workflow needs onward export, write a changed sample through that route and inspect it in the next recipient. Do not call the process reversible merely because the first receiving screen looked correct.

Count photographs, expected values and relationships separately. Twelve image records, eleven populated captions and seven collection memberships could all be correct if documented in advance. A single total cannot reveal that two same-named originals were confused while the number of rows remained unchanged. Inspect the deliberately awkward examples as well as aggregate counts.

Make the acceptance note specific: “This twelve-image JPEG/TIFF/RAW packet, with these versions and options, retained the listed fields; hierarchy required an external record.” That is useful evidence. “All metadata compatible” is much broader than the exercise supports. Repeat the qualification after changes to the writer, receiver, relevant settings or export route, rather than treating one historical success as permanent certification.

Expand the migration only after agreeing its exceptions

The next step is a controlled batch, not an immediate move of the entire archive. Choose one contained job that includes real examples of the features that matter, using a backed-up working copy. Keep the source program and original organization available. Do not combine migration with deduplication, bulk renaming and a new storage layout unless each operation has its own checked record. Combining changes makes a later discrepancy harder to locate.

Give each known exception a practical owner. If hierarchy is retained only in a report, who can consult that report when an image request arrives? If custom fields are archived read-only, where will a corrected value be recorded? If collections are reconstructed manually, who compares membership and order? An exception is managed only when the studio knows how the next task will work despite it.

Define rollback before accepting the batch. Keep the old catalog and its supported dependencies, the original packet, the new catalog and the conversion notes separately identified. Reopening an untouched source after a failed test is different from attempting to reverse changes already written into every original. If the migration writes embedded metadata, record that behavior and retain a suitable prior copy rather than assuming a catalog backup can restore image-file bytes.

Check one real retrieval request against the new arrangement. Ask someone to locate the intended family photograph, identify its album membership and read the caption without relying on your memory of the migration. That exercise can expose an operational failure that a field-by-field inspection misses. It also reveals whether the external exception record is understandable to the person who will use it.

Then sign off the actual batch scope and unresolved limits. Record how many source records were assessed, which relationships were checked, which files remain offline and what still needs review. An offline reference may be intentionally preserved, while a wrong online original is a different and more urgent problem. Keep those categories separate before starting the next batch. This makes a large migration a sequence of accountable decisions rather than a single hopeful import.

What this means for a Lightbox Pro migration

Lightbox Pro’s reviewed development build 0.1.2 (65) provides native catalog ratings, labels and nested sets. Its supported legacy importer can retain specified descriptions, keywords and named custom fields as read-only import information. That preservation does not establish a general metadata editor, keyword search or XMP writeback. Current text search is filename-only.

Build 65 also adds a bounded internal corrected-output metadata policy. It can carry 20 allowed photographic fields, including camera/lens facts, dates, numerical exposure values, title, caption, creator, copyright, keywords and credit. Explicitly supplied catalog values can override descriptive fields, with optional rating and label output. This is encoding metadata into a prepared derivative, including verified XMP values; it does not write those changes back to originals or provide a finished graphical export command.

For inherited descriptive fields, an absent override retains the verified source value; an explicit empty value clears it. A separate omission policy excludes photographic metadata. Conflicting aliases require explicit resolution. GPS, serial numbers, MakerNotes, arbitrary XMP, embedded previews and stale pixel-layout tags are excluded from this copying policy. These choices concern internal output preparation, not a completed client-facing privacy feature or universal metadata preservation. Finished export controls and guarded file publication remain unfinished, so use a proven production route while evaluating the catalog.

Original iView MediaPro binary import is limited to the verified internal 025i JPEG/TIFF/PSD profile. The documented 24- and 133-photograph historical restoration cases support those cases, not every .ivc catalog. XML is a separate import route. Custom legacy label names and colors are not reconstructed as their original native vocabulary. Read the supported import procedure before testing a catalog copy.

Retain the source catalog, originals and a record of relationships that matter. Compare the import review and reopened result with the old evidence. If your daily task needs writing searchable keywords back into files, keep an established, tested writer while evaluating Lightbox’s catalog role. The useful migration is one you can explain and recover, including the limitations you deliberately accepted.

Sources and verification

Official references reviewed 21 October 2026. Prices, service terms, versions and supported systems can change. Application statements use Lightbox Pro development build 0.1.2 (65), source 3f3e29f11e2ae18a2d93cc2337c16e6fc6172550. Native test results are recorded engineering evidence rather than tests rerun on this Windows website workstation.

• IPTC: Photo Metadata Mapping Guidelines, version 2023.1
• Adobe: XMP Basic namespace
• Adobe: save metadata to XMP and ACR sidecars in Lightroom Classic
• Adobe: current Lightroom Classic Smart Collection criteria

Zippi Technologies is the developer of Lightbox Pro, independently of the other companies named. Product references do not imply affiliation or endorsement. Current local features, unfinished development and future ambitions have different acceptance requirements.