Central storage is not the same as shared meaning
Moving records into one database does not automatically resolve disagreements between applications. Two systems may use the same product identifier while assigning it different meanings. A customer record may also represent an organization in one application and an invoicing account in another.
The first task is to define the concepts being shared. Distinguish an offer available for purchase from a product already subscribed to, and distinguish the customer relationship from the network identifiers used to deliver a service.
Publish a contract for the shared record
A consuming application needs to know which fields are authoritative, which relationships are mandatory and how a record changes over time. It also needs a reliable way to reference the record without embedding assumptions about another system's database.
Versioning becomes relevant when a commercial definition changes. An existing subscription may need the conditions accepted when it was ordered, while a new order needs the offer currently available to that customer.
Plan updates and reconciliation together
Events can tell consumers that a change occurred, but a consumer may miss an event or restart during processing. A query or reconciliation mechanism is therefore useful alongside the event contract. The two mechanisms should agree about identifiers and effective dates.
For a migration, define a baseline snapshot, the handling of changes during the transfer and the checks used to compare source and target records. Treat unresolved differences as work with an owner rather than silently choosing the newest timestamp.
- Document product, customer and account definitions.
- Assign an authoritative owner to shared attributes.
- Define effective dates and consumer update behavior.
- Provide a way to detect and resolve divergent records.