Migrating data into Business Central with RapidStart: built-in validation, and the Excel row limit

If you're standing up a new Dynamics 365 Business Central company, RapidStart Services is the tool Microsoft gives you to load the setup and master data. The heart of it is the configuration package: you pick the tables you care about, export them to Excel, fill them in, and import them back – and Business Central validates every record on the way in, with the same logic it would apply if a user typed it by hand.

That validation is the whole reason to use RapidStart rather than poking data straight into tables. But the Excel round-trip that makes it so approachable also sets a hard ceiling, and on any real dataset you'll bump into it. Here's an honest look at how it works, what it's good at, and where you have to split your data to get it in.

How RapidStart works: configuration packages

A configuration package is a curated bundle of tables plus the field selection and rules for loading them. The flow is the same every time:

1. Create the package and add the tables you need. Business Central knows the table relationships and suggests related tables so you don't miss a dependency.
2. Choose fields and set the processing order per table, mark required fields, and optionally attach configuration templates that fill default values automatically.
3. Export to Excel – one worksheet per table – or to a .rapidstart file (compressed XML).
4. Fill or transform the data in Excel. This is the part clients and functional consultants like: it's a familiar tool, not a database.
5. Import the file back. The data lands in the package's staging area, not yet in the live tables.
6. Validate, then apply. Apply writes the data into the real Business Central tables, running the same field validation and business logic as manual entry.

One important boundary, straight from Microsoft: configuration packages are meant for setting up a company for the first time, not for pushing data into a company that's already in production.

The reason to use it: validation on apply

This is RapidStart's headline benefit, and it's a real one. When you apply a package, Business Central doesn't just dump rows – it runs the same field validation and table-relationship checks as if someone keyed each record in the UI. A customer that points at a payment-terms code or posting group that doesn't exist gets rejected with a per-record error, not quietly written as broken data.

In practice that means a tight loop: import → validate → read the errors → fix them in the package → re-apply. You're cleaning data against the actual Business Central configuration before it ever becomes live. Add to that:

• No code. Functional consultants and the client's own team can drive it.
• Templates apply consistent defaults to imported master records.
• Processing order lets you respect dependencies (setup and reference tables before the masters that reference them).
• Reusability. Export the package once and re-import it into another company or environment – your "golden setup" becomes portable.

The ceiling everyone hits: Excel's row limit

Here's the catch the demos skip. Because the data is staged through Excel, you inherit Excel's limits. An Excel worksheet maxes out at 1,048,576 rows, and one sheet holds one table. A large table – a long customer or item list, ledger or opening-entry data – can blow past that. And well before the hard cap, the Excel import gets slow and memory-hungry; tens of thousands of rows already drag.

So on a real migration you split the data across multiple files and import them one after another into the same package. Each import appends to the package's staging, and you validate and apply once at the end. Practical ways to split a big table:

• By a natural range – a number-series block, a date range, a region or dimension value.
• Into evenly sized chunks (e.g. 50–100k rows per file) that import quickly and are easy to re-run if one fails.

Two ways to dodge the Excel cap entirely when a table is genuinely huge:

• Export/import the package as a .rapidstart file instead of Excel. It's compressed XML and isn't bound by the worksheet row limit – you lose the convenience of editing in Excel, but you carry far more data.
• Step outside RapidStart for the heavy tables – use the APIs (or the built-in Cloud Migration tooling, below) for volume, and keep RapidStart for the curated setup and master data where its validation earns its keep.

Where RapidStart fits among the options

RapidStart isn't the only way data gets into Business Central – it's the right one for a specific job:

• RapidStart configuration packages – setup/configuration data, master data, and opening balances for a new company. Validated, no code, business-led. This is the default for a fresh implementation.
• Cloud Migration (Intelligent Cloud) – for moving an existing on-premises Dynamics GP, NAV, SL or BC database to Business Central online. It replicates data wholesale and can run repeatedly (initial full load, then deltas) – a different job from RapidStart's curated, first-time setup.
• APIs / automation – for high volume, repeatable loads and integrations, where you've outgrown the Excel round-trip.

Most greenfield implementations lean on RapidStart; an upgrade from on-prem GP/NAV leans on Cloud Migration. Choose deliberately.

Where RapidStart stops – and you take over

The validation is genuinely helpful, but be clear about what it does and doesn't catch:

• It checks references, not correctness. A record can be perfectly valid – every code resolves – and still be wrong. Validation won't tell you the customer's credit limit or tax setup is the wrong value.
• Quality and mapping are upstream. Deduplication, cleansing, and mapping legacy codes (customer groups, item categories, dimensions) onto the Business Central setup happen before the package, not inside it.
• Order matters. Number series, posting setups and reference tables must be applied before the master records that depend on them – plan the processing order, don't discover it through errors.
• History is a scope decision. RapidStart shines for setup, masters and open items; deep posted history belongs in Cloud Migration or left in the legacy system. Decide early – it drives your timeline more than the tool does.
• Reconciliation is still manual. A clean apply proves the rows went in and validated; proving counts and balances match the source, and getting sign-off, is your discipline.

In summary

RapidStart configuration packages are the right tool for setting up a new Business Central company: the validation on apply catches broken references before they become live data, it needs no code, and a package is reusable across companies. Just plan for the Excel ceiling – split large tables across multiple files imported into one package, or switch to the .rapidstart format or APIs when the volume demands it.

And, as always, the tool is the last mile. Cleansing the source, mapping it to the Business Central setup, deciding what history to bring, and reconciling the result – the work that decides whether the migration succeeds – sits outside RapidStart.

Standing up Business Central and weighing how to migrate? Get in touch – I'm happy to share how I work.

---

References: Microsoft Learn – Set up company configuration packages, Apply company configuration packages, and Migrate on-premises data to Business Central online.