Still on BusinessVision? A Practical Migration Planning Guide

If you are still running Sage BusinessVision in 2026, you already know its limitations. This is not a post to convince you to leave. It is a post to help you think clearly about what leaving actually involves.

Sage has set December 31, 2026 as the end-of-life date for BusinessVision. After that, no updates, no tax table support, no patches. The software will still run, but it will drift further from compliance requirements and further from the integrations your business needs.

Here is what a practical migration plan looks like.

Step 1: Understand what you actually use

Most BV users use about 40 percent of the software. Before you evaluate replacements, document what your team actually does in BV every day. Not what the software can do. What your people do.

Typical BV workflows that need to carry forward: sales order entry, invoicing, inventory management, purchasing, AP, AR, GL, and reporting. Some clients also use payroll, production, and job costing. Some have built Crystal Reports that they rely on heavily.

Make a list. This becomes your requirements document and it is more useful than any vendor feature matrix.

Step 2: Evaluate your data

This is where most migration anxiety lives, and where most of it is unnecessary.

Your BV data falls into three categories:

Must migrate: Open transactions (unpaid invoices, outstanding POs, pending orders), current balances (AR, AP, GL), active customer and vendor records, and current inventory levels. This data has to come over clean and verified.

Should migrate: Historical transactions from the past two to three years. Sales history for reporting, payment history for credit decisions, purchase history for reorder planning. Most clients want this, and it migrates well.

Can archive: Anything older than three years. It does not need to live in your new system. Keep BV installed as a read-only archive for lookups, or export historical data to a structured format for reference.

The biggest data challenge is not volume. It is quality. BV databases accumulate drift: duplicate customers with slightly different names, inventory codes that were reused, GL accounts that were created for a one-time transaction and never cleaned up. A good migration partner catches this during the data review phase and fixes it before anything moves.

Step 3: Choose your timeline

Work backwards from December 31, 2026. A typical BV migration takes eight to ten weeks from kickoff to go-live. That means your latest practical start date is mid-October 2026.

But starting earlier is better for two reasons. First, you avoid competing with every other BV user who waited. Second, parallel testing (running both systems simultaneously) is less stressful when you are not racing a deadline.

The ideal window is Q2 or Q3 2026. You go live with time to spare, run through at least one month-end in the new system while BV is still available as a fallback, and enter 2027 fully settled.

Step 4: Budget honestly

Software licensing is the easy number to quote. It is also the smallest part of the real cost. Budget for three things:

Software and implementation. The license, data migration, configuration, and training. This is the number your partner quotes.

Internal time. Your team will spend time in data review, parallel testing, training, and the cutover itself. For a five-user BV shop, expect roughly 40 to 60 hours of total staff time spread across the project. For larger teams, more.

Contingency (10 to 15 percent). Data cleanup takes longer than expected. A Crystal Report needs rebuilding. A workflow you forgot to document surfaces during parallel testing. Budget for surprises and be glad when they are small.

Step 5: Pick the right partner

The ERP is important. The partner is more important. Three questions that will tell you what you need to know:

How many BV migrations have you done? Not ERP implementations. BV migrations specifically. The data model, the export process, the character encoding quirks, the way BV handles multi-currency: these are things you learn from doing the work, not from reading documentation.

Who is doing the implementation? Not the company. The person. What is their name, what is their experience, and will they be available the week you go live?

What happens after go-live? The first month on a new system is when questions come fastest. What does support look like? Is it the same team that did the implementation, or a call center?

What we recommend

We are a Spire ERP partner. We have migrated hundreds of BV clients to Spire over the past decade. We recommend Spire because we know it is the closest functional match to BV with a modern architecture underneath.

But more than the software, we recommend starting now. The companies that plan their migration in Q2 have a better experience than the ones that start in Q4. The data is cleaner, the training sticks better, and nobody is panicking about a deadline.

If you want to talk through what your specific migration would look like, we are happy to do that in a 30-minute call. geminilogic.com