Migrating an Incubator Off Spreadsheets

Start with the next cohort, not the current one

The instinct is to move everything at once, so the new system is complete. It is the wrong instinct and it produces the one genuinely bad outcome: two systems in use at the same time, indefinitely, with nobody sure which is right.

Run the next intake in the new system from the application form onwards. Leave the current cohort where it is until it graduates. You will spend a few months with a live programme in each, which sounds untidy and is far safer than moving a cohort mid-flight.

Decide what actually has to move

Not everything is worth importing. Three tiers:

Must move - things you will act on:

• Startups currently in a programme
• Active funding commitments, with what has been released and what has not
• Current space allocations and their deposits
• Open applications, if an intake is in progress
• Mentors currently attached to a programme

Worth moving - things you will report on within the year:

• Last twelve months of graduated startups
• Funding disbursed in the current financial year
• The current cohort's stage history

Leave behind - archive the spreadsheet and move on:

• Applications from previous years that were not accepted
• Historical mentor session logs
• Old space allocations, closed and settled
• Anything you have not opened in a year

The instinct to import five years of applications is strong and almost always wrong. The effort is large, the data is inconsistent, and the old file stays readable. Put it somewhere safe and label it.

Do the definitions before the data

This is the part people skip and the part that determines whether the migration is worth anything.

Before importing a row, settle:

• Your stage list. Three or four stages, named, with what each means. Your spreadsheet almost certainly has six variations of the same three.
• What "active" means for a startup. Still in the programme? Still trading? Still in touch?
• Headcount definition. Founders in or out. FTE or headcount.
• Revenue definition. Recognised or collected.
• Who owns what - which member of staff is responsible for which programme.

Import with fuzzy definitions and you get a clean-looking system holding the same ambiguity you had before, now harder to see because it looks official.

Clean while you move, not after

A migration is the only moment when someone will look at every record. Use it.

As you go, resolve:

• Duplicate startups under slightly different names
• Companies that have quietly ceased trading but are still marked active
• Funding commitments that were never released and never formally stopped
• Space allocations for startups that left
• Mentors who have not been contacted in two years

That last-but-one is worth its own line. Committed-but-never-released funding is the most common thing found during a migration, and it usually frees money that has been silently reducing what you could allocate.

Set the permissions before anyone logs in

If everyone is imported as an administrator "for now", that is what you will have in three years.

Decide up front:

• Who administers the portal - two people, not one, and not eight
• Who runs each programme, and can they see other programmes?
• Who touches funding? Usually a smaller set than expects to.
• What can an external evaluator see, and when does it end?
• What can a startup see of its own record?

The finance separation matters most. A programme manager who can also release funding is a control weakness that an auditor will find, and it is far easier to set correctly at the start than to take away later.

A workable order

1. Decide the definitions. Stages, statuses, headcount, revenue, ownership.
2. Set up one programme, the next intake, with its application form and rubric.
3. Configure permissions, including the evaluator role.
4. Import current startups, with their current stage.
5. Import active funding - commitments, releases, what remains.
6. Import space allocations, with deposits.
7. Run the intake live in the new system.
8. Set a cut-off date for the spreadsheet, and announce it.
9. Archive the old files somewhere findable and read-only.

Step 8 is the one that determines success. Without a date, both systems stay in use forever, and the question "where is the current version" never has an answer again.

Tell the startups something

Founders notice when the process changes, and silence makes it feel like an imposition.

One short message covers it: what is changing, what they need to do differently, what they get out of it - usually being able to see their own applications, requests and funding status rather than emailing to ask. Frame it as fewer emails for them, because that is true.

What good looks like a month later

• One place holds the current cohort, and nobody opens the spreadsheet to check
• A new application arrives, is scored, and the score breakdown is retained
• Somebody outside your team can be given evaluator access without a conversation about risk
• A funder question about a specific disbursement is answered in minutes
• The spreadsheet is archived, read-only, and nobody has asked for it in two weeks

If the spreadsheet is still being updated a month in, the migration has not failed - it just has not finished, and the missing step is almost always the cut-off date.