When a transaction register needs more than a spreadsheet.
A spreadsheet can be a practical operational register. Migration becomes useful when the team can name a constraint it will solve: concurrent editing, inconsistent fields, reporting performance, access requirements or dependable history. Changing storage alone does not repair unclear definitions.
Written by the Fundamental View editorial team. Updated 28 October 2026. This is a migration-planning guide, not a promise of unlimited scale, security or automatic compliance.
Identify the constraint before choosing the replacement
Record the tasks becoming difficult. Is the same transaction entered twice? Do people use different entity names? Are evidence links missing? Does a report depend on a formula only one person understands? Separate problems requiring better operating rules from those requiring different storage or application controls.
There is no universal transaction count at which every team should migrate. Record complexity, access, reporting, concurrency and available support all affect the decision.
| Observed constraint | Possible requirement | Acceptance test |
|---|---|---|
| Concurrent edits collide | Controlled multi-user writes | Two authorised test users edit different records without losing changes |
| Entity and status values drift | Validated reference data | Unsupported values cannot silently enter the register |
| Evidence links break | Explicit record-document relationships | Every sampled row retrieves the intended source with proper access |
| Reports become slow | Defined queries and appropriate indexing | Agreed reports complete within the measured target on representative data |
| Corrections lack history | Configured change events or audit design | A test correction retains the required reviewer and timestamp context |
| Permissions are too broad | Role-specific access architecture | Each test role can and cannot perform its intended actions |
Preserve identifiers and evidence relationships
Define fields before moving them. Each record needs stable identity, and linked documents need a clear relationship to that identity. Document dates, currencies, amounts, statuses and entity fields. Keep original values needed to explain later transformations. If a field changes during migration, record its mapping. Do not replace missing information with a plausible value to satisfy a new table constraint.
Evidence links deserve separate checks. A successful data import is incomplete if the register points to files the responsible team cannot access.
Plan the transition around a bounded sample
- Select straightforward records and exceptions: incomplete documents, corrections, internal transfers and different currencies.
- Define expected results before import, including identifiers, counts and relevant totals.
- Compare using the same scope and conventions; investigate differences rather than relying on one overall total.
- Test duplicate handling and the preservation of unresolved states.
- Agree when the original register stops accepting changes and who owns the cutover.
- Document recovery if acceptance fails.
Test handover, not only import
Ask ordinary users to find a record, open its evidence, correct a field through the agreed process and produce a relevant output. Check access and support responsibilities. Include a failed-permission test and a retrieval test by someone who did not perform migration.
SQL is storage technology. Permissions, change history, backups and recovery depend on the surrounding implementation and must be configured and verified. The database label alone is not a security guarantee.
How Fundamental View approaches migration
Fundamental View can begin with a Google Sheets register in the client's own Workspace. SQL migration is considered where the agreed operating scope requires it and is a separate implementation decision. Historical migration and additional integrations require their own scope, acceptance tests and responsibilities. Preserve a documented rollback path until every acceptance case has passed.
Related guides
- Create the field dictionary before migration
- Assign acceptance cases and owners
- Test evidence relationships after import
- Include migration in software selection
Discuss your workflow
Describe the record-keeping problem you want to solve. Please do not include confidential financial information or documents in the enquiry.
Discuss implementation