Choose the decision owner and the triggers
Name one person who can call a rollback and one person who can confirm the technical state. Write triggers that can be observed, such as a required record type missing, a critical association broken, or a team unable to complete a core task. Decide how long the team will observe the new system before making that call.
Set thresholds with the people who rely on the workflow. A small number of missing records may be serious in one process and tolerable in another. Do not borrow a generic percentage. Record who accepts a known gap and what evidence supports that decision.
Describe what the snapshot contains
List each record type, field group, relationship, activity, attachment, and configuration item that matters. Record when the export was taken, who created it, and where the file can be retrieved. Check a few records and links so the team knows the file opens and contains the expected fields.
HubSpot's record export documentation describes current property values and associations, while pointing to separate methods for certain activity data. Its scope is therefore narrower than a blanket "full account backup." Identify additional exports or copies you need, and do not treat an export as complete until you have checked its contents.
Plan for changes made after the snapshot
The old export becomes less complete as people keep working. Decide whether to pause updates during the cutover, keep a change log, or reconcile later changes by hand. For every new or edited record, capture enough information to recreate the work if the team returns to the old system.
The recovery plan should also cover the destination. Notion's current import guidance, for example, says CSV imports add rows rather than updating existing ones and that a new CSV import cannot create new relations or formulas. Those are Notion-specific constraints, but they demonstrate why the ability to export one system does not establish that another can restore it cleanly.
For a fictional cutover on 3 November at 09:00, record the old system snapshot taken at 08:50 and log every accepted change afterward. If a required company relationship is missing, the named decision owner pauses new writes and checks the agreed return trigger. Reconcile the logged changes before resuming the old workflow, so returning does not silently discard work completed after 08:50.
Fictional post-cutover changes that a return must account for
- Change ID: CH-01; Time: 2026-11-03 09:12; Record: C-014; Change after snapshot: Customer confirmed a new billing contact; Evidence: Saved confirmation message REF-01; Recovery owner: Morgan; Recovery state: Not replayed; verify the authorized change before updating
- Change ID: CH-02; Time: 2026-11-03 09:25; Record: D-008; Change after snapshot: Team sent the revised proposal; Evidence: Saved proposal version V03 and send record; Recovery owner: Jordan; Recovery state: Not replayed; preserve the version and recorded send event
- Change ID: CH-03; Time: 2026-11-03 09:31; Record: T-021; Change after snapshot: Owner changed from Jordan to Riley; Evidence: Handoff note REF-03; Recovery owner: Riley; Recovery state: Not replayed; confirm ownership in the resumed workflow
Test the return route before cutover
Use a small set of fictional or approved test records to rehearse the proposed export and import path. Confirm that the destination can accept the fields and relationships you intend to restore, and note anything that must be recreated manually. Do not run a rollback rehearsal on production data unless the system owner has approved that method.
If no safe rehearsal is available, list the untested steps and assign an owner to resolve them before cutover. A plan that depends on an unknown export permission, missing relationship field, or undocumented import behavior is a list of assumptions, not a tested recovery route.
Keep the decision usable during the change
Put the trigger, owner, latest snapshot, and change log where the people making the decision can find them. During the switch, record new work in a consistent format and note which system currently owns each update. If the team chooses to stay with the new system, keep the same evidence long enough to close open questions.
After the change, review the plan against what actually happened. If the team did not preserve a type of activity or could not restore a relationship, update the checklist before the next software change.
Using Areinum
Ask Areinum Assistant to organise the rollback owner, triggers, snapshot scope and post-change work into a plan for review. The system owner checks and rehearses the actual return route before cutover.
See the example
Software change rollback readiness plan
All names, owners, sample evidence, and statuses in the plan are fictional.
| Work item | Owner | Evidence to preserve | Acceptance check | Rollback trigger | Status |
|---|---|---|---|---|---|
| Record snapshot | Jordan Vale | Fictional export of current properties and associations | Open the file and compare selected records | Required records or links are absent | Planned |
| Activities and files | Morgan Lee | Separate activity and attachment inventory | Confirm each required category has a recovery path | A required category has no usable copy | Planned |
| Post-cutover changes | Riley Chen | Fictional change log for new and edited work | Recreate a sample change in the old workflow | The team cannot account for important new work | Planned |
| Destination import | Casey Park | Test mapping and relation notes | Check a small test set in an isolated destination | Required fields or links cannot be restored | Planned |
| Decision record | Avery Cole | Named owner, review time, and agreed triggers | Decision maker can locate the current evidence | No authorized owner can make the call | Planned |
- Replace the example owners and checks with the people, records, and systems in your change.
- Set rollback triggers before the cutover, then record which evidence proves each check. Keep the post-cutover change log current until the team closes the rollback decision.
- The rows describe a fictional plan. They do not show that an export, backup, or rollback was actually tested.
Plan for changes made after the snapshot
| Change ID | Time | Record | Change after snapshot | Evidence | Recovery owner | Recovery state |
|---|---|---|---|---|---|---|
| CH-01 | 2026-11-03 09:12 | C-014 | Customer confirmed a new billing contact | Saved confirmation message REF-01 | Morgan | Not replayed; verify the authorized change before updating |
| CH-02 | 2026-11-03 09:25 | D-008 | Team sent the revised proposal | Saved proposal version V03 and send record | Jordan | Not replayed; preserve the version and recorded send event |
| CH-03 | 2026-11-03 09:31 | T-021 | Owner changed from Jordan to Riley | Handoff note REF-03 | Riley | Not replayed; confirm ownership in the resumed workflow |
Limits of this method
- The selected research supports export and import mechanisms, not a validated rollback procedure or a measured need for rollback planning.
- A rollback may lose work created after the snapshot or omit activities, files, permissions, and configuration. Confirm the exact scope and rehearse the recovery route with the system owner.
Questions you may have
Is an export the same as a tested rollback?
No. Check what the export contains and rehearse how it would be restored in the system and configuration you intend to use.
What happens to work created after the snapshot?
Record those changes and their evidence so the responsible people can decide how to recover or replay them if the team returns.
Who decides when to roll back?
Name a decision owner and the conditions that should trigger review before the change. The owner uses the actual situation and the plan to make the call.
Can Areinum restore the old system if the change fails?
The example prepares the plan for review. The system owner must check and rehearse the actual recovery route.
Sources and further reading
- Export your records
HubSpot documents that record exports include current property values and associations, and lists separate methods for some activity data.
This is provider documentation about specified HubSpot exports, not proof that an export is a complete or restorable backup.
2026-10-18 - Import data into Notion
Notion's import documentation describes supported file types and states that CSV imports add rows, do not update existing rows, and cannot create new relations or formulas through a new CSV import.
These are Notion-specific import rules. They do not describe the behavior of every destination or establish a universal rollback limitation.
2026-10-18
The demo uses sample company data. Access may need to be arranged.
Explore the demo