Data Migration

Migrating a real, currently-operating business's data (from a platform like OfficeRnD, Nexudus, or similar) needs to be treated as its own careful project, not a quick import.

Principles

• Dry-run before executing. Extract, transform, and validate the data fully before writing anything to the real database, and review the dry-run output against the source system by hand for at least a sample.
• Map products and rates explicitly. Don't assume a source system's "plan" or "rate" concept maps 1:1 onto this platform's resources and products — resolve each mapping deliberately, especially for individually-negotiated rates.
• Preserve history, don't fabricate it. A real historical audit trail (if the source system has one) is worth carrying over structurally distinguishable from live-system activity, rather than blending imported and organic records indiscriminately.
• Suppress notifications during migration. A customer being imported shouldn't receive a flood of "your booking is confirmed" emails for bookings that already happened months ago on the old system. Customers mid-import can be flagged so the normal notification crons skip them until their real cutover date.
• Watch for test/seed data contamination. Confirm which records in the source system are real customers versus test/seed data before importing — importing test rows as if they were real customers pollutes reporting in ways that are hard to untangle later.

A real example worth learning from

This platform's own former-customer migration split into two tracks: a large batch of historical (no-longer-active) customers, and a much smaller, higher-stakes batch of currently-active leases and registered-office accounts — migrated separately, with the active batch requiring individually-resolved rate overrides and getting a full before/after reconciliation pass rather than a single bulk run.