Key takeaways
- Inventory add-ons, custom queries and integrations before choosing a date.
- Rehearse the migration on a copy of production, at least twice.
- Plan for performance testing and user retraining, not just data conversion.
- Write a rollback plan and agree who can trigger it.
Why this migration deserves its own plan
When a company runs SAP Business One on a traditional database and considers moving to the HANA edition, the conversation often starts as an infrastructure question. In practice the database change touches queries, add-ons, integrations, reports, backups and the way users experience the system. Teams that treat it as a lift and shift are the ones who discover surprises during cutover weekend.
This checklist is written from the perspective of risk. It does not replace vendor documentation or a formal assessment, but it helps you ask the right questions early.
Risk 1: things you did not know you had
Over the years, Business One installations collect custom queries, user-defined fields, formatted searches, crystal reports, scheduled jobs and small scripts written by people who may have left. Any of these can behave differently on a new database, especially where SQL was written with assumptions about the old one.
- List every custom query, report, stored procedure and scheduled job, with an owner for each.
- Identify add-ons and confirm with each vendor that a version supported on the target platform exists.
- Document integrations, including web stores, banking files, EDI and BI extracts, and how each connects.
Risk 2: version and compatibility gaps
Compatibility depends on your current Business One version, the target version and every component around it. Check supported upgrade paths and the sequence required, since some routes need an intermediate step. Confirm client versions, operating system and infrastructure requirements early, because hardware and licensing lead times can dominate the schedule.
Risk 3: data conversion surprises
Old data has quirks: inconsistent codes, orphaned records, unusual characters and long-forgotten test entries. A conversion exposes them. Run data quality checks before migrating and decide what to clean, what to archive and what to leave. Reconcile totals after each rehearsal, for example trial balance, open receivables and payables, and inventory value by warehouse, so you can prove nothing changed in the move.
Risk 4: performance is not automatically better
A new database platform can speed up some workloads, but poorly written queries and heavy custom reports do not fix themselves. Test the operations that matter most to your business, such as month-end close, large reports, mass price updates and peak-hour order entry, using realistic data volumes. Compare against the current system and record the results.
Risk 5: people and process
Even when screens look the same, some behavior and reports may differ. Plan short training sessions, publish a list of known differences and have a support channel during the first weeks. Choose the cutover date away from month-end, year-end and your commercial peaks.
Rehearse, then decide go or no-go
- Migrate a copy of production and run the reconciliation checks.
- Have key users test their daily work and their reports against a written script.
- Fix issues, repeat the rehearsal and time each step so the cutover window is realistic.
- Hold a go or no-go review with named criteria, not a general sense of readiness.
Finally, write the rollback plan. It should state exactly how to return to the previous system, how long that takes, what data entered after cutover would be lost or need re-entry, and who has authority to call it. Backups that have never been restored are only a hope, so test a restore.
