Migrating from BG-BASE, Excel or Access: What to Expect

Every garden that switches collection management systems asks the same first question: will our data survive the move? It is the right question, since the records are the point, but the honest answer is more nuanced than yes or no. Data survives migration in proportion to how well it was structured to begin with, and the migration itself is usually the best data-quality project a garden ever undertakes.

Here is what the process actually looks like, based on the three starting points we see most often.

Starting point 1: BG-BASE

BG-BASE has served botanical institutions for decades, and its data model is genuinely botanical: accessions, plants, names and sources are distinct, which means the conceptual mapping to another purpose-built system is largely one-to-one. The work lies in the details:

• Field conventions. Long-running BG-BASE databases accumulate local conventions: codes in note fields, overloaded columns, in-house abbreviations. These need to be catalogued before migration so they land in proper structured fields rather than a notes dump.
• Multi-value fields. BG-BASE’s underlying database allows multiple values in one field. Each of these needs an explicit decision: does it become a related record, a delimited list, or the first value with the rest preserved in notes?
• Verification and determination history. This is scientifically valuable data. Insist that it migrates as structured history, not flattened into a single current name.

A typical BG-BASE migration is therefore less about rescuing data and more about translating conventions, which is tedious in places but low-risk when done systematically.

Starting point 2: Excel

Spreadsheets are where most small-garden record systems begin, and their weaknesses are well known: no enforced structure, silent typos, one row trying to describe both an accession and several plants. Expect the migration to surface issues such as:

• The same taxon spelled four ways (Acer pseudoplatanus, A. pseudoplatanus, Acer pseudoplantanus…)
• Dates in mixed formats, some of them ambiguous (is 04/05/1998 April or May?)
• Location described free-text (“near the old pond, west side”) rather than against a defined list of garden areas
• Rows that were duplicated for a second plant of the same accession, then edited inconsistently

None of this is fatal. The standard approach is to normalise in passes: first taxa against a reference list, then locations against a newly agreed garden-area hierarchy, then dates, then the residue by hand. A few thousand rows of spreadsheet records are usually reviewable in days, not months, and the garden ends up with a controlled vocabulary it never had before.

Starting point 3: Access (or another home-built database)

Home-built databases sit between the two: there is structure, but it reflects one person’s design decisions, often someone who has since retired. The critical first step is archaeology: documenting what each table and column actually means, ideally with the original author in the room. Watch for:

• Lookup tables whose codes are no longer documented anywhere
• Relationships enforced by habit rather than by the database, with orphaned records to match
• Reports that quietly filter data, so the database contains more (or less) than anyone believed

Once the schema is understood, migration proceeds much like BG-BASE: map entities, translate conventions, migrate history rather than snapshots.

What a good migration process looks like

Whatever the source, the sequence is consistent:

1. Inventory the source. Every table, column, code list and convention, written down.
2. Agree the target structures. Garden areas, source types, name references: the controlled lists that free-text data will be mapped onto.
3. Trial migration. Migrate a full copy into a test database. Curators then try real tasks against it and hunt for anomalies.
4. Fix at the source or in the mapping, not by hand in the target. Corrections belong in a repeatable script so the final run is clean.
5. Final migration and cut-over. A defined records freeze, the production run, and verification counts: accessions in, accessions out, per status and per garden area.
6. Keep the source read-only. The old database is an archive and an audit trail. Retire it from editing on day one, but never delete it.

The part nobody budgets for: people

The hardest part of switching systems is rarely the data. It is habits. Records staff have years of muscle memory in the old system, and a migration succeeds when training is planned as seriously as the data work: real tasks, the garden’s own data, and a defined period where the records team can ask questions daily. Budget as much calendar time for adoption as for the technical migration and the project will feel calm rather than heroic.

How long does it take?

For a collection in the low tens of thousands of accessions: a spreadsheet migration is typically measured in weeks; Access and BG-BASE migrations in one to a few months, driven almost entirely by how many local conventions must be untangled and how quickly decisions can be made. The single best predictor of a fast migration is not the software on either end. It is having one person with the authority to decide, promptly, what each ambiguous convention should become.

The reward at the end is real: not just the same records in a newer system, but cleaner, better-structured records than the garden has ever had.