NextConcierge: Preparing Your Data for Migration

Who this is for: agencies sending us a data export so our team can bring your book into NextAgency for you. This is the guide to read before you pull those files, and it is linked from the file request we send when we are quoting or starting a migration.

Not sure this is your path? If you are loading your own data through the import tools in the portal, read Preparing Your Spreadsheet for Import instead. The advice differs in several places, most of all on record IDs and on how to organize commission files, so it is worth being on the right guide.

First, the good news

You do not need to clean your data up before you send it. That is the work you are handing to us. Messy carrier names, information spread across columns instead of down rows, names and addresses crammed into one cell, duplicates, blanks, decades of odd formatting: all of it is normal, and all of it is handled on our side.

What we need from you is narrower than most agencies expect:

• An export that is complete and undamaged
• The record IDs from your current system, if you can get them
• Answers to a short list of questions only your team can settle

This guide is about those three things. Section 1 is worth more than all the rest combined, so read that one even if you read nothing else.

1. Include your record IDs

What they are

Your current system gives every record its own internal ID number: a client ID, a policy ID, a commission or transaction ID, a note ID, a document ID. You almost never see them day to day, and most exports leave them out unless you ask.

These IDs are the most valuable thing in your export.

Why they matter

An ID is a fact. A name is a description.

If your policy file includes the client ID for each policy, we do not have to work out who that policy belongs to. We know. Same for a commission row that carries a policy ID, or a note that carries the ID of the client it was written about.

With IDs on your files, your data lands with complete accuracy. There is nothing to interpret and nothing to correct later.

What happens without them

The migration still works. We match instead on what is available: client name, date of birth, policy number, carrier, product type, dates. That handles the large majority of your book.

The trouble is the rest. Names are not unique. In a book of any size you have clients who share a name, sometimes a parent and child with the same first and last name, sometimes two people with no connection at all. When the name is the strongest thing we have to go on, one client's records can land on the other. Nothing is lost, and your totals still look right, but individual records sit on the wrong person. That is the kind of problem that surfaces months later when a report reads low, and it takes real work to unwind.

So: with IDs, accuracy is certain. Without them, accuracy is high but not guaranteed, and the gaps land exactly where you would least want them.

How to get them

Most systems can include IDs in an export. They just do not by default. Send your current provider a request along these lines:

Please include your internal record IDs in our data export: the client or account ID, policy or benefit ID, commission transaction or payment ID, note ID, and document ID. Where records relate to each other, please include the parent ID on the related record as well, for example the client ID on each policy row and the policy ID on each commission row.

That last sentence is the part people miss.

An ID only helps if it appears on both sides

A client list with client IDs and a policy list with no client ID on it leaves us no better off. Each file needs its own ID and the ID of whatever it belongs to.

Please do not tidy the ID columns

IDs tend to look like clutter. They are long, they start with zeros, they mix letters and numbers, they repeat down the file. Leave them exactly as they come:

• Do not delete an ID column because it looks meaningless.
• Do not trim, reformat, or renumber them.
• Do not strip leading zeros. 009123456 and 9123456 are different values to a computer.
• After your data is loaded, do not edit any field in NextAgency that ends in (ID). Those are what we use to trace your records back to the source while we validate.

2. Send the file the way your system produced it

This is the most common way good data gets damaged, and it happens before the file ever reaches us.

Spreadsheet programs treat anything that looks like a number as a number. Open an export, save it, and you can silently lose:

We have seen a single open-and-save pass damage several thousand policy numbers, which made thousands of policies look like they were never imported when they were sitting there the whole time.

What to do

Best: send the file straight out of your system without opening it. If you want to check what is in it, open it, look, and close without saving.

If you need to open or edit it, protect the columns first.

In Excel, do not double-click a CSV to open it. Instead:

1. Open a blank workbook.
2. Go to Data then From Text/CSV and choose your file.
3. In the preview window, click Transform Data (or Edit).
4. Select each ID, policy number, phone, and ZIP column and set its data type to Text.
5. Load, then save as CSV UTF-8 or Excel Workbook.

In Google Sheets:

1. File then Import.
2. Under import options, uncheck "Convert text to numbers, dates, and formulas."

If you have already edited a file, send us the original export alongside your edited copy. Comparing the two takes us minutes and removes all doubt about which values are real.

Two quick checks before you send

• Look at your policy number and ID columns. Do the leading zeros still show? Is anything displaying as 9.12E+08?
• Look at your date columns. Are years shown with four digits, and does the oldest date look plausible?

Name your files clearly

Use content and date, for example clients-2026-08-12.csv and policies-2026-08-12.csv. Send one copy of each. When we receive export.csv, export (1).csv, and export (2).csv, we cannot tell which is the real one, and picking wrong costs days.

3. Ask for everything, not the tidy version

We would rather have your complete, messy book than a clean subset.

• Remove any date filter. Exports often default to the last few years. Your longest-standing clients are the ones most likely to notice missing history later.
• Leave the rows you think are irrelevant. Terminated policies, inactive clients, chargebacks, zero-dollar lines. Negative and zero amounts matter when we reconcile.
• Send all parts of a multi-part export, and tell us the total, for example "clients: 33 files, policies: 39 files." Missing parts from the middle of a set are very hard to spot from the outside.
• Tell us the date you pulled the export. Anything that happens in your old system after that date will need a final top-up file at cutover. Knowing the date up front means we plan for it instead of finding a gap.
• Watch for size limits. A spreadsheet holds just over one million rows per tab. Large commission histories can spill onto a second tab or get cut off with no warning. If your export is very large, CSV is safer, and please tell us if you see a second tab.

4. Tell us what the totals should be

This is the highest-value five minutes you can spend on your migration.

Before you send the files, run your own reports and write down what you expect to see:

• Total clients, total prospects, total policies
• Active policies by carrier
• Commission dollars by carrier, and by year if you can get it
• Counts of notes, tasks, and documents

Send those numbers with the files. They let us prove your data came across completely rather than tell you it did, and they let us catch a problem during validation instead of after you are working in the system. When your reports and ours agree to the dollar, you can stop wondering.

5. Choosing how the export comes out

You do not need to clean your data up. Reshaping, splitting, standardizing, and deduplicating are our work, not yours. This section is only about the choices your own system gives you when it produces the file, because those choices are yours and they are worth a minute of thought.

If your export screen offers options, these are the ones we prefer:

If your system gives you none of those choices, send whatever it produces. A wide export with everything spread across columns, names in one cell, addresses mashed together, four spellings of the same carrier, blank rows at the bottom, a banner above the headers: all of that is routine, and all of it is handled on our side.

The one exception is section 2. However the file comes out, please do not open and re-save it, because that damages values rather than untidies them.

6. What you can leave to us, and the few things only you can answer

The left column is what agencies most often apologize for. None of it needs fixing before you send the files.

The short list of things we genuinely need from you is everything else in this guide, plus answers to a few questions only your team can settle:

• What each date column means in your system: sold, effective, renewal, terminated, paid.
• Whether premium figures are monthly or annual.
• What your statuses mean, and whether you want to keep segmenting your book the way you do today.
• Your convention in the handful of cases the data cannot settle on its own, such as which product a payment belongs to when the statement does not say and the client holds two.
• Broker of record, if your system holds it. Include the column when it is available.

7. Commission history

Commissions have the strictest requirements of anything we bring across, because every commission row has to attach to one specific policy.

The most valuable thing you can put on a commission row is your system's policy or benefit ID. If your commission export carries the same policy ID that appears on your policy export, the two files join exactly. Every payment lands on the policy it was actually paid for, with nothing left to interpretation. Add the transaction or payment ID as well and each individual payment stays traceable back to your source data, which is what lets us prove your totals to the dollar rather than assert them.

Without that ID, commissions have to be matched instead on carrier, policy number, and product type. That works for most rows, but it is inference rather than fact, and it is where the ambiguity concentrates:

• Policy numbers that are blank, or written differently on your records than the carrier writes them on the statement
• The same policy number used by two different carriers
• A client holding two products with one carrier, where the statement does not say which product a payment relates to

Reconciling that is usually the single largest piece of work in a commission migration. A policy ID on the commission rows removes it. It is worth going back to your current provider specifically for this one: "please include the policy or benefit ID on the commission export, not just on the policy export."

What to include:

• The policy or benefit ID on every row, if you can get it. This is the one that matters most.
• A transaction or payment ID on every row, so each individual payment is traceable.
• Policy number and carrier on every row regardless, as the fallback and as a cross-check.
• One file covering everything is fine. You do not need to split your history out by carrier for us. Send the master export exactly as your system produces it, with the carrier named on each row, and leave the sorting to us.
• Every date column, labeled. Statement date, paid-to date, and date received are different things, and they are easy to confuse. Tell us which is which.
• The premium column, if your statements carry one.
• Chargebacks and negative amounts, left in.
• Producer and sub-agent splits, with the payee, the rate, whether the rate is a percentage of commission, a percentage of premium, or a flat amount, and whether the split ends.
• What one row represents. Some systems produce one row per statement. Some produce one row per payee on that statement. Some produce both a total line and separate payee lines. All are fine, we just need to know which, because a file that lists each payment three times looks like three times as much data as it is.

If you can tell us how many statements you expect per carrier per month, that is another useful total to check against.

8. Documents, notes, and attachments

Documents are the hardest thing to reattach, because a PDF contains nothing that says which client it belongs to.

The best deliveries look like one of these:

• Folders named for the record ID, with the files inside. Several systems export this way by default and it works very well.
• A manifest: a spreadsheet listing each file name next to the ID of the client, policy, or note it belongs to.

Two things to check before you send:

• If your export includes an attachments report, look at the column that identifies the parent record. It is sometimes completely blank, and it is much better to find that out now.
• Send every part of a multi-part archive, and tell us how many there should be.

And please do not rename the files or reorganize the folders. Those names are what we match on.

9. Two minutes on the file itself

This is not a review of your data. It is a quick look at whether the export came out whole, which is the one thing we cannot tell from our side.

1. Row count. Click a column letter and read the count in the status bar. Does it look like your whole book, or did the export stop early?
2. Ctrl + End. Does the data end roughly where you expect? A jump to row 900,000 usually means the export was cut off at a limit.
3. Every file arrived. If your system produced a set of numbered files, are they all there, and does the highest number match the total it promised?

Then pick one client you know inside out and keep them in mind. You are not checking their record now. They are your benchmark for later: when we tell you a stage is loaded, that is the client to open first, because you will spot something wrong on them in seconds that would take an hour to find anywhere else.

10. What to tell us when you send the files

A short note with the upload saves a lot of back and forth. Something like:

• Files attached: clients, policies, commissions, notes, documents
• Export pulled on: [date]
• Record IDs included: yes for clients and policies, no for commissions
• Totals from our reports: 4,182 clients, 9,540 policies, commissions by carrier attached
• Commission rows are one per payee, per statement
• Date columns: "Stmt Date" is the carrier statement date, "Paid" is when we received it
• Heads up: we have two clients named John Smith, father and son, and neither record has a date of birth on it

None of that is required. Every line of it saves a round trip.

That last line is only worth writing when there is nothing in the data to tell the two apart. If your export carries record IDs, or even dates of birth, we can separate namesakes ourselves and you do not need to think about them at all.

11. What to expect from us

• A field map to confirm. We show you where each of your columns is going before we load anything. This is the cheapest moment to catch a misunderstanding.
• One consolidated list of questions. Where your data cannot tell us something (which product a payment belongs to, which of two same-named clients owns a policy), we ask rather than guess. We batch those into a single list. Answering it in one sitting is the biggest thing you can do to shorten your migration.
• A load in stages. Your data comes across in pieces rather than all at once, because later pieces attach to earlier ones. The exact order depends on what is in your export and how it is structured, and we will tell you the plan for yours before we start.
• A review point at each stage. It is far easier to check one thing at a time than to check everything at the end, and a correction caught early is a small one.
• Honesty about gaps. If something in your file cannot be rebuilt, we will show you rather than fill it in with a guess.

Two things that speed everything up: authorizing us up front to correct obvious data problems (a missing policy number that appears on the carrier statement, an inconsistent carrier spelling) rather than approving them one at a time, and leaving the (ID) fields alone once your data is in.

Before you send: checklist

Worth noticing what is not on this list. There is nothing here about tidying, standardizing, or deduplicating anything. Every item is either something only you can obtain, or something that protects the file on its way to us.

Printing this page gives you the checklist to work through while you pull the export.

If there is something on this list you cannot provide, tell us instead of working around it. Knowing where your data is thin is what lets us plan for it.

A few terms we use