This playbook is about doing it the right way, so the app you land on is genuinely better than the spreadsheet you left — not just relocated.

Why a spreadsheet isn’t an app (the mental shift)

A spreadsheet is one flat grid. Everything lives in the same rectangle, so if a customer places three orders, their name and address get typed three times. Relationships are implied by whatever’s next to what, and integrity depends entirely on people being careful.

An app thinks in entities and relationships. A customer is one thing. An order is another. An order belongs to a customer. Store each fact once, link the rest. In Creator, the building block is the form — both the screen you enter data on and the underlying table it’s stored in. Every record automatically gets a system ID and audit fields (added time, modified time, who created it), so the plumbing you were faking with formulas comes for free.

The single most important decision in your whole migration happens before you upload anything: how many forms should this spreadsheet become, and how do they relate?

Get that right and everything downstream is easy. Get it wrong and you’ve rebuilt the swamp.

Step 1Audit the spreadsheet before you touch Creator

Open the file and interrogate it. What is one row actually about? Is every row the same kind of thing, or has the sheet quietly become two or three different things stapled together? Which columns repeat the same value over and over — a sign they belong in a separate, linked table? Which columns are really formulas, not data? Which are notes, statuses or one-off hacks you can drop entirely?

Write down, in plain language, the “things” your spreadsheet tracks and how they connect. “Customers have many orders. Orders have many line items.” That sentence is your data model, and it’s worth more than any import wizard.

Step 2Model relationships instead of flattening them

Now translate that sentence into forms:

• Each distinct “thing” becomes its own form. Customers, Orders, Products — separate forms, not columns on one giant form.
• Link them with lookup fields. A lookup on the Orders form pointing to Customers means you pick a customer once and never retype their details. That’s the relational backbone a spreadsheet can’t give you.
• Use subforms for genuine one-to-many detail. Line items on an order — the classic child-rows case — belong in a subform on the parent record. Keep subforms for true detail lines, not as a dumping ground; they have practical size limits, so a relationship with thousands of children per parent is better modelled as its own linked form.

This is the step people skip, and the one that determines whether your app ages well. Splitting a flat sheet into related forms is the whole point of the exercise.

Step 3Choose real field types, not “text for everything”

A spreadsheet cell is just text with a format. Creator gives you a couple of dozen field types, and choosing correctly is what makes the app smart. A date field enables calendar views and date logic. A dropdown or radio field enforces valid choices instead of hoping people spell “Complete” the same way twice. A number or currency field lets you aggregate. An email or phone field validates format on entry. Map each column to the type that matches its meaning, and half your old data-quality problems disappear at the door.

Step 4Clean the data, then import

Creator’s smart import can build an app straight from an uploaded spreadsheet, with dedicated tools for Excel and Google Sheets plus a scheduled migration path for MS Access. Use them — but feed them clean input. Before importing:

• Standardise inconsistent values. One spelling of each status, consistent date formats.
• Split combined columns. A “Name” column into first/last if you’ll ever sort or filter by them.
• Remove the formula columns you’ll rebuild as logic, and the junk columns you decided to drop.

Import your parent tables first (Customers, Products), then the tables that reference them (Orders), so the lookups have something to point at. If the importer offers to auto-build one form from the whole file, resist. Bring the data in against the model you designed in Steps 1 and 2.

Step 5Rebuild the logic (and mind the import gotcha)

Your VLOOKUPs and formula columns become formula fields and workflows. A calculated total is a formula field. “When an order is marked shipped, email the customer” is a workflow. This is where the app starts doing work the spreadsheet never could.

Step 6Add the guardrails a spreadsheet never had

This is your chance to make bad data impossible instead of merely discouraged. Mark the fields that must always be present as mandatory. Set “no duplicate values” on the fields that identify a record uniquely (an email, an order number) so you never get two of the same. Add validations on entry. These are the integrity rules you were enforcing by nagging colleagues — now the app enforces them for you.

Step 7Verify, then build outward

Before you switch anyone over, reconcile. Does the record count match? Do the totals tie back to the spreadsheet? Do a handful of spot-checked records look right? Only once the data is trustworthy do you build the parts that make the app worth having: reports and dashboards over the clean data, and the mobile version (every Creator app is automatically a native iOS/Android app), so the people who lived in the spreadsheet get something genuinely better on day one.

The traps to avoid

• Uploading the raw file and calling it done. You’ll have copied the mess, not fixed it. Model first.
• One giant form. A single form with fifty fields almost always means you flattened relationships that should be separate linked forms.
• Text fields everywhere. You throw away validation, aggregation and every smart view. Pick real types.
• Assuming import-time workflows touch every row. They don’t past the first few thousand. Batch it or backfill.
• Skipping the reconciliation. Trust is earned once, at the start. Verify the migration before anyone depends on it.