If you are running Sage BusinessVision, you already know the clock is ticking. You have seen the sunset notices, and you are likely already weighing or planning your move to Spire.

What is harder to find is a straightforward, practical account of what actually happens once you hand over your data.

Because Spire provides direct, built-in conversion tools for BusinessVision, moving your data is far closer to a turnkey process than migrating off older, non-BV software. But turnkey does not mean instantaneous, and it does not mean flipping a switch on a Friday afternoon.

Here is what the conversion path actually looks like, how your data gets used along the way, and why the trial phase is your best safeguard before go-live.

 

The Real Sequence: From Tailored Demo to Working Sandbox

A proper conversion begins long before your actual cutover weekend. In fact, it starts before you even sign a contract.

The first step is handing over a backup copy of your BusinessVision data. We take that backup and run it directly through Spire's native conversion tools. At this stage, we do not adjust settings or clean up messy records. We let the data come over exactly as it sits in BusinessVision.

This raw conversion serves two critical purposes:

  1. A tailored demo using your real operations. Instead of watching a sales rep click through generic sample data for a fictional bicycle company, you see your own customers, your active items, and your actual order history inside Spire. You can immediately see how your daily workflow looks in the new interface.
  2. A working sandbox for setup and training. If you decide to move forward, that converted database becomes your non-production sandbox. This is where we design and print sample invoices, purchase orders, and packing slips to test your custom forms. It is where we build custom reports against your real numbers. Most importantly, it gives your team a zero-risk environment to train and practice daily tasks without touching live operations.

Treating this initial conversion as a sandbox is deliberate. It acts as a diagnostic window, revealing exactly what needs to be adjusted before you commit to a live cutover.

The Surprises That Surface in the Data

When a business runs the same system for ten, fifteen, or twenty years, data quirks accumulate. These are not signs of a broken software platform; they are simply the natural result of decades of real-world operations, changing staff, and evolving processes.

Because Spire's conversion routines are thorough, they hold up a clear mirror to your historical data. Running that initial conversion often brings several common situations to light:

  1. Trial balances out of balance. In older datasets, historical general ledger balances sometimes do not balance cleanly. While this does not prevent you from using the sandbox for training, it is something that must be reconciled before the final cutover.
  2. Missing date fields halting a conversion. Occasionally, specific historical transaction rows lose a date value over time. Spire requires valid dates to build its relational database, so an empty date field will pause the conversion routine until that specific record is corrected.
  3. Negative inventory running millions in the red. If a company used BusinessVision primarily for order processing and invoicing rather than full inventory management - recording sales without entering purchase orders - items set as physical inventory will steadily accumulate negative balances. Seeing an inventory valuation millions of dollars in the red can be jarring, but it is simply a configuration mismatch.
  4. Decades of inactive accounts and obsolete items. Companies with data stretching back before 2000 often carry thousands of former customers and discontinued parts. Spire will convert every record it finds, bringing legacy clutter right along with active accounts.
  5. Dormant warehouses carrying forward. Spire converts every warehouse set up in BusinessVision, even locations unused for a decade. Because modern ERP systems maintain strict audit trails and resist deleting tables with historical activity, those old warehouses will remain visible unless addressed.

 

What Real Cleanup Looks Like Before Go-Live

The entire reason for running a sandbox conversion months before your target launch date is to give you time to address these findings without operational pressure.

Cleanup is a shared effort between your team and your implementation partner:

  • What you can clean up before the final conversion. For obsolete items, inactive customers, or dormant warehouses, the best strategy is often to archive and purge very old history inside BusinessVision before running the final live export. For mass updates, providing spreadsheets of accounts or parts to mark inactive allows your consultant to batch-update records rather than having your staff edit them one by one.
  • What your consultant fixes under the hood. For structural hurdles like missing date fields, out-of-balance ledgers, or resetting negative physical inventory to non-physical items with zeroed-out balances, an experienced partner works behind the scenes to adjust the data so the live conversion runs cleanly.

Treating data cleanup as a deliberate, methodical phase ensures that when go-live day arrives, you are moving into a clean, well-structured environment.

What This Means for Your Timeline

A data conversion done properly is not a single weekend event. It is a phased process that runs parallel to your planning and training.

When an implementation partner pauses to point out an out-of-balance subledger, missing transaction dates, or obsolete master records during the sandbox phase, that is not a setback. That is the system working exactly as intended. Finding and resolving data oddities in a sandbox takes time, but it protects your live business from disruption.

A partner who catches these quirks early is protecting your go-live. A process that rushes past the sandbox stage without scrutinizing the converted data simply defers those problems to day one of live operations, when fixing them is far more stressful and disruptive.

Taking the time to test forms, verify reports, and clean up historical clutter turns go-live day from an anxious gamble into an orderly non-event.

 

Taking an Honest Look at Your Data

If you are currently running BusinessVision and planning your next move, you do not need to have all your data sorted out before you start talking to a partner.

The sandbox conversion exists specifically to show you where things stand. Running a trial conversion against a backup copy of your data gives you a clear, factual starting point. You will see what converts cleanly, what needs a quick adjustment, and what your team might want to clean up before cutover.

Before you set an arbitrary launch date on the calendar, take an honest look at your data first. If you want to see what your BusinessVision data looks like inside Spire and walk through a realistic transition plan, the door is always open.

 

Most companies imagine  ERP go-live day as a stressful, all-hands scramble. Systems crashing. Panic in the conference room. Late nights and everyone bracing for impact.

It makes for a good story. It's also a sign that something went wrong long before launch day.

A good ERP go-live day should feel calm. Not boring. But controlled. Yes, there's always a little last-minute energy. It's like moving day: no matter how prepared you are, you're still packing a few boxes the morning the truck arrives. But the big decisions are made. The system is tested. You're not solving problems. You're executing a plan.

You check the boxes, run the first real transactions, confirm the numbers tie out, and go home at a reasonable hour.

If that sounds anticlimactic, good. That's the goal.

The difference between a chaotic go-live and a calm one isn't luck. It's what happens in the weeks before anyone flips the switch.

 

What Has Already Happened Before ERP Go-Live

 By the time go-live day arrives, most of the real work is already done. That's the point.

Here's what should be complete before anyone enters a live transaction:

Test conversion completed.
Your data has already been moved into a test environment at least once. This is where you catch the surprises: duplicate records, missing fields, formatting issues. Better to find them here than in production.

Sandbox validated.
Someone has actually clicked through the system. Created a test order. Run a report. This isn't a demo; it's a dress rehearsal. And it needs to include the people who'll use the system daily, not just leadership. I've seen go-lives where the owner and accountant tested everything thoroughly, but staff never touched it until day one. They were fine because leadership knew the product well enough to answer questions on the fly. But that's not a plan. That's luck.

Workflow questions resolved.
How will you handle returns? Who approves purchase orders? Where does this report live? These conversations are boring. They're also the ones that stall a go-live when they happen too late.

 Custom forms finalized.
Invoices, packing slips, purchase orders. Anything client-facing should already match your branding and include the fields you need. You don't want to discover a missing column the first time you send a real invoice.

User permissions configured.
Everyone has access to what they need and nothing they don't. This sounds simple until you realize someone can't post a payment and the owner is out of the office.

Training done in the real environment.
Not slides. Not a video from the software company. Hands-on time in the system they'll actually use, with their actual data. By go-live, the basics shouldn't feel new.

 If any of this sounds like a lot, it is. But it's the kind of work that happens over weeks, in manageable pieces. Go-live day is just the moment all that preparation becomes official.

 

What Actually Happens on a Well-Run ERP Go-Live Day

Go-live day has a rhythm. If the preparation was done right, it feels methodical, not frantic.

Here's what happens, step by step:

Final data backup.
One last snapshot of the old system before anything changes. If something goes sideways, this is your safety net.

Controlled cut-off from the legacy system.
The client finishes entering their last transactions in the old system. After this point, the old system is for lookup only. No new orders, no new invoices, no new payments. The books are closed.

Data conversion or import.
This is where the data moves. If there's a conversion tool, I run the conversion. If not, we import from the spreadsheets the client has already cleaned up. Either way, the data lands in the live system.

Data integrity checks.
Now we verify. Did everything come through? Are there obvious errors, missing records, or duplicates? This is a quick scan before we get into the detailed comparisons.

Balance comparisons.
We run reports in both systems and compare:

  • Vendor balances (AP)
  • Customer balances (AR)
  • Inventory valuation
  • General ledger balances

Old system to new system. Line by line. If something doesn't match, we stop and figure out why before moving forward.

 

What We Confirm Before Going Live

 Before we move to live transactions, three things must be true:

  1. Financial totals tie out.
    The core balances in the new system match what we expect from the old system. No unexplained differences. No "we'll figure that out later."
  2. Inventory makes sense.
    Counts and valuations are directionally right. Nothing is missing, duplicated, or valued at zero when it shouldn't be.
  3. The system is ready for a real transaction.
    Not a test. A real order, a real invoice, a real payment. We're confident the workflow will hold.

Only when all three are confirmed do we move to the next step.

 

The First Live Transaction

This is the moment everything has been building toward. And if you've done the work, it's almost anticlimactic.

The balances tie. The data is verified. The old system is locked down. Now it's time to see the new system do what it's supposed to do.

Pick something real.
Not a test order with fake data. A real customer, a real invoice, a real workflow. This is where you find out if the system works the way everyone expects.

Walk it through end to end.
Enter the order. Check inventory allocation. Generate the invoice. Post it. Send it. Every step that will happen a hundred times next week should happen once, right now, with someone watching.

Confirm it lands correctly.
Does the invoice hit the right GL accounts? Does inventory decrement properly? Does the customer balance update? This isn't about trusting the software. It's about trusting your setup.

If the first transaction runs clean, you're live. Not "sort of live" or "live but still figuring things out." Actually live.

If something breaks, you catch it now, with one transaction to fix, not fifty.

This is why the preparation matters. A clean first transaction isn't luck. It's the result of everything that came before it.

 

What Does Not Happen on a Good ERP Go-Live

A good go-live is defined as much by what doesn't happen as by what does.

On go-live day, you should not be:

Figuring out your chart of accounts structure.
That conversation happens weeks earlier. If you're debating account numbers while trying to convert data, you're not ready.

Debating workflow decisions.
Who approves what? How do returns work? Where do these transactions post? These questions are fine in discovery. On go-live day, they're a red flag.

Designing forms from scratch.
Invoices, packing slips, purchase orders. If you're building these on go-live day, you're going to be sending ugly documents to real customers while you figure it out.

Teaching basic navigation.
Users should already know where to click. Go-live day is for answering "what do I do in this specific situation," not "how do I create an invoice."

Migrating 30 years of messy history at the last minute.
You don't need every transaction from 2003. You need clean opening balances and enough history to operate. Deciding what to bring over is a planning conversation, not a go-live conversation.

If any of these are happening on go-live day, it's a sign that something got skipped earlier. The day itself isn't the problem. The preparation was.

 

Why ERP Go-Live Should Not Feel Dramatic

There's a certain mythology around go-live. The all-nighter. The war room. The heroic scramble to fix something at the last minute.

That makes for a good story. It does not make for a good implementation.

ERP success is not about a dramatic launch. It's about a stable transition.

When go-live is calm:

Teams adopt faster.
People learn better when they're not stressed. A quiet go-live gives users space to get comfortable instead of just survive.

Fewer errors occur.
Rushed decisions lead to mistakes. When there's no panic, people take the time to do things right the first time.

Confidence builds immediately.
The first few days set the tone. If those days feel controlled, users trust the system. If those days feel chaotic, they start looking for workarounds.

Support requests stay manageable.
A calm go-live means questions trickle in instead of flooding in. That gives you time to answer thoughtfully instead of just putting out fires.

This is why the phased approach matters. Every decision made earlier, every workflow tested in the sandbox, every form reviewed before go-live day, all of it exists to make the actual transition feel almost boring.

Boring is the goal. Boring means it worked.

 

Common ERP Go-Live Mistakes I've Seen

I've seen a lot of go-lives. The ones that struggle tend to share the same patterns.

Skipping sandbox testing.
"We'll figure it out in production." This sounds efficient until you're fixing live data in front of real customers. The sandbox exists for a reason. Use it.

Underestimating cleanup time.
Data cleanup always takes longer than anyone expects. Old duplicates, inconsistent naming, customers who haven't ordered in a decade. Cleaning this up is tedious work, and it can't be rushed. Build more time into the schedule than you think you need.

Waiting to train until after launch.
The logic seems reasonable: why train people on a system that isn't live yet? But users who see the system for the first time on go-live day are learning and working at the same time. That's a recipe for mistakes and frustration. Training happens before go-live, not during.

Over-customizing to match the old system.
"Can we make it look like what we had before?" Sometimes, yes. But chasing the old system's quirks often means fighting the new system's strengths. The goal isn't to replicate what you had. It's to work the way the new system was designed to work.

None of these mistakes are fatal on their own. But stack a few together, and a go-live that should have been smooth turns into a scramble.

 

The Bigger Message

A good ERP go-live day is not the finish line. It's the starting point.

The system is live. The data is clean. Transactions are flowing. But that doesn't mean the work is done. It means the real work is beginning.

Post-go-live optimization.
The first few weeks will reveal things you couldn't see before. Reports that need tweaking. Workflows that could be smoother. Small friction points that only show up when people are using the system every day. This is normal. Plan for it.

Gradual adoption of advanced features.
You don't need to use everything on day one. Start with the core workflows. Get comfortable. Then layer in the more advanced capabilities when the team is ready. Trying to do too much too fast is how systems get abandoned.

Continuous refinement.
A good ERP isn't something you set up once and forget. It evolves with your business. New products, new processes, new reporting needs. The companies that get the most value from their systems are the ones that keep refining them over time.

Go-live is a milestone, not a destination. The goal was never just to get the system running. The goal is disciplined operations, and that's a practice, not an event.

Where to Start

If your current implementation plan relies on figuring things out during go-live, it's not a plan.

A real plan means decisions are made before go-live day. Workflows are tested. Data is clean. Users know what to do. The day itself is just execution.

If that's not where you are, there's still time to fix it.

If you're mid-project and something feels off, let's talk. An implementation review can spot what's been missed before it becomes a go-live day problem.

If you're still in the planning stages, start with my Migration Readiness Checklist. It walks through what to expect and how to prepare before moving to a new system, from data cleanup to team preparation to cutover planning.

Either way, the goal is the same: a go-live day that feels boring. Because boring means it worked.

 

~Audrey Quick, Founder of AGS Enterprises Consulting LLC

Audrey has spent 35+ years helping businesses manage ERP implementations and accounting software transitions.  If you're evaluating your options, we can book a free 15-minute call 

Download Migration Readiness Checklist
Book A Call

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

Book A Call

~Audrey Quick, Founder of AGS Enterprises Consulting LLC

Audrey has spent 35+ years helping businesses manage ERP implementations and accounting software transitions.  If you're evaluating your options, we can book a free 15-minute call