AI app guides
Before replacing an Emergent app, decide which records must survive
Use a data inventory and reconciliation checks when a new project takes over an existing live application.
Zocri · 2 min read · Sources checked
Inventory the information people depend on
Emergent's publishing guide distinguishes Re-publish from Replace and describes a database choice when a forked project replaces an existing published app. Treat that choice as a business decision. In a membership app, names, membership status, past payments and uploaded documents may each matter. Write down which information must remain available and which preview examples should never enter the live system.
Identify the authoritative copy of every important record. If staff have continued working in the existing live app while the replacement was built, the preview may be older. A newer interface can still contain older information, so do not choose a data source by appearance alone.
Define a cutover window
Agree when the final comparison will happen and whether staff can continue making changes during it. If work must continue, plan how changes made after the initial copy are captured. Give one person responsibility for deciding when the record set is ready to use.
Create a practical recovery reference before the switch using supported backup or export options. Verify what that reference includes: records, attachments, relationships and necessary settings. A file with a list of names may be useful, but it may not be enough to reconstruct a working membership system.
Reconcile a small set and the totals
Compare counts by meaningful category, such as active, expired and suspended memberships. Then inspect several representative records, including one with a recent update and one with an attachment. Matching totals alone cannot reveal that values were assigned to the wrong people.
Check that existing users can reach their own records and that private data stays private. Test a new signup after the switch as well. The app must handle both historical information and new work; a successful migration screen cannot prove either customer journey on its own.
Make the replacement reviewable
Write a release note identifying the version, the data choice and the checks performed. List unresolved differences explicitly and decide whether each prevents release. Keep the old reference available for the agreed recovery period, with access limited to the people who need it.
After publishing, watch the first ordinary transactions and reconcile them with the owner's view. Confirm that staff know which address and version to use. A replacement succeeds when the business can continue its work with the intended records, and everyone can identify the system that now owns them.