Migrate your Adobe Campaign data

The nms:recipient schema is the primary profile table. Standard fields (email, format preference, address) are stable and map cleanly. Custom fields added via schema extension land as custom properties and require field-level mapping during migration.

BroadLog records track every message sent across channels. We preserve campaign attribution and send timestamps, but v8's FFDA architecture splits logs between local and cloud databases — cross-reference by delivery ID is required to assemble a complete history.

Campaign metadata (labels, dates, type, status) is stored in the nms:campaign schema and migrates as a structured object. Associated workflows and tasks require dependency ordering that we handle through graph traversal.

Opt-in subscription records link Recipients to Services. Subscription status and subscription date are preserved, but double-opt-in confirmation flags may need value-mapping depending on the destination platform's preference center logic.

Programs are hierarchical containers for Campaigns in Standard and v8. Folder structure and program labels migrate, but program-specific permissions do not and must be reconfigured at the destination.

Custom tables created via nms:ext: namespace or FDA-linked external schemas require custom extraction logic. We inspect the schema XML to derive the underlying SQL table structure before mapping to the destination object model.

Targeting workflows, campaign workflows, and technical workflows can be exported as XML packages. Dynamic content blocks and queryDef expressions frequently break across ACS-to-ACC migrations and require post-migration template adaptation.

Delivery definitions (email content, SMS text, push payload, routing parameters) migrate as templates. Content personalisation tokens resolve against the imported Recipient schema. Static assets referenced by URLs require separate asset migration planning.

Enumerations defined in schema XML (e.g. deliveryStatus, gender) may have different internal values in the destination. We maintain a value-mapping table keyed by enumeration name and map to destination IDs at import time.

Seed addresses are internal testing records used for proofing. They are instance-specific and not designed for cross-platform portability. We do not migrate seed addresses and recommend rebuilding proofing lists at the destination.

Tracking logs (open, click, bounce) are stored in NmsTrackingLog. We preserve click-through URLs and timestamped events for reporting continuity, but aggregate open/click rates are recalculated at the destination.

Control groups (exclude populations from delivery targeting) are stored as query definitions linked to the delivery. We extract the exclusion criteria and reapply them as filter rules at the destination.