Leaving Navision Behind: A Practical NetSuite Migration Roadmap

Migrating from Microsoft Dynamics NAV, still called Navision by many long-time users, to Oracle NetSuite is not just a system replacement. It is a chance to rebuild the way finance, operations, inventory, purchasing, order management, reporting, and controls work across the business.

We see NAV environments that have served companies well for years. They contain valuable transaction history, deeply familiar workflows, custom reports, and business-specific logic. They also carry the weight of older architecture, local servers, heavy customization, difficult upgrades, disconnected systems, and reporting processes that rely too much on spreadsheets.

A successful Dynamics NAV / Navision to NetSuite migration respects both sides of that equation. We do not treat NAV as a problem to erase. We treat it as the historical record of how the business operates, then use NetSuite to create a cleaner, more scalable foundation.

This guide walks through how we plan and execute a NAV to NetSuite migration, what decisions matter most, and how to avoid the issues that delay ERP projects.

Why companies move from Dynamics NAV to NetSuite

Dynamics NAV has a long history. It gave mid-market companies strong accounting, inventory, purchasing, and operational capabilities long before cloud ERP became the default choice. For many organizations, NAV still runs core processes every day.

The challenge is that many NAV environments reached a point where the business outgrew the platform, the architecture, or the customization model. Common drivers include:

• Aging infrastructure, including servers, local databases, VPN dependencies, and workstation-specific access issues

• Complex customization, where years of modifications make upgrades expensive and risky

• Reporting delays, especially when finance teams export data to Excel to combine entities, departments, or operational metrics

• Fragmented systems, with separate tools for CRM, ecommerce, expenses, payroll, warehouse operations, or planning

• Manual month-end close, driven by reconciliations, journal entry workarounds, and offline schedules

• Limited real-time visibility, especially for multi-entity, multi-currency, subscription, project, or inventory-heavy businesses

• Succession risk, where internal NAV knowledge depends on a small number of people or an external partner with limited availability

NetSuite solves these problems with a cloud-native ERP model, unified data, role-based dashboards, built-in financial consolidation, configurable workflows, SuiteAnalytics, and a broad integration ecosystem. The migration is not about swapping screens. It is about moving from a system that records the business to a platform that helps run the business in real time.

We use a similar modernization mindset across ERP migrations. For example, companies evaluating other legacy Microsoft ERP paths should also review our guide on Microsoft Dynamics GP migration to Oracle NetSuite, since many of the planning principles overlap.

Start with the business case, not the data export

The first mistake in a NAV to NetSuite migration is starting with tables, fields, and scripts before confirming the business outcome.

Data matters. Migration tools matter. Mapping matters. But ERP projects succeed when the business case is clear. Before we touch the technical migration plan, we must define what NetSuite must improve.

Strong migration goals look like this:

• Shorten the monthly close by reducing manual reconciliations

• Replace spreadsheet reporting with NetSuite dashboards and saved searches

• Standardize the chart of accounts, departments, classes, locations, and subsidiaries

• Create cleaner order-to-cash and procure-to-pay processes

• Improve inventory accuracy and demand visibility

• Eliminate duplicate data entry between NAV and surrounding systems

• Support expansion into new products, entities, currencies, or markets

• Improve audit readiness through stronger permissions, approvals, and system controls

Weak migration goals sound like “move everything from NAV into NetSuite.” That approach imports old complexity into a new platform. We prefer a migration strategy that preserves what matters, redesigns what is broken, and leaves behind obsolete process debt.

Understand the NAV environment before designing NetSuite

NAV implementations vary widely. Two companies running Dynamics NAV rarely operate the same way because NAV historically allowed deep customization. Some businesses have standard modules with a light configuration. Others have years of custom C/AL or AL code, industry-specific add-ons, custom pages, custom tables, and integrations written for very specific workflows.

Before configuring NetSuite, we document how NAV operates today.

Key discovery areas include:

This analysis prevents surprises. It also gives us the information needed to decide what belongs in NetSuite, what belongs in an archive, and what should be redesigned instead of migrated.

Decide what historical data belongs in NetSuite

Historical data is one of the most important migration decisions. It is also one of the easiest places to overcomplicate the project.

Many teams initially ask to migrate every transaction from NAV into NetSuite. In practice, that approach adds cost, lengthens testing, introduces reconciliation challenges, and loads the new ERP with years of old structure that no longer fits the business.

We recommend a deliberate historical data strategy.

Common options include:

• Open balances only, where AR, AP, inventory, bank, and GL balances are migrated for go-live

• Current year plus prior year, useful when teams need comparative reporting inside NetSuite

• Summarized historical GL, where monthly trial balances are migrated by account and segment

• Detailed historical transactions are reserved for cases where operational or compliance requirements justify the added work

• Read-only NAV archive, where legacy detail remains accessible outside NetSuite for audit, research, and historical reporting

The best answer depends on reporting needs, audit requirements, system performance, and how much the new NetSuite structure differs from NAV.

We are direct about this because it matters: migrating less history into NetSuite is often the cleaner decision. Historical access does not require historical clutter inside the new ERP. The goal is to make NetSuite the system of record going forward, with reliable access to prior information where needed.

Our data migration work emphasizes cleansing and transformation before loading. The importance of clean migration logic is also illustrated in our data-focused case study, From Chaos to Clean - How 180 Lines of Python Cut 120 Hours from a NetSuite Data Migration.

Map NAV dimensions to NetSuite segments carefully

NAV dimensions are powerful, but they do not automatically translate into NetSuite one-for-one.

In NAV, dimensions support reporting across departments, cost centers, projects, regions, and other business attributes. In NetSuite, the equivalent structure might use:

• Subsidiaries

• Departments

• Classes

• Locations

• Custom segments

• Projects

• Items

• Customers

• Vendors

• Custom fields

This is not a simple field mapping exercise. It is a reporting architecture decision.

We start by asking what finance and leadership need to see after go-live:

• Profit and loss by department

• Revenue by product line

• Margin by customer, channel, region, or location

• Expenses by cost center

• Project profitability

• Inventory movement by warehouse

• Consolidated reporting across subsidiaries

• Budget versus actual by segment

Then we design the NetSuite structure around those outcomes. This is where many migrations either gain or lose long-term value. If segments are too broad, reporting lacks detail. If segments are too granular, users struggle with data entry and the system becomes harder to govern.

The right design gives the business meaningful reporting without turning every transaction into a burden.

Redesign customizations instead of rebuilding them blindly

NAV customizations deserve careful review. Some represent genuine competitive processes. Others exist because the old system lacked a feature that NetSuite already provides.

During migration planning, we classify each customization into one of four categories:

• Replace with native NetSuite functionality

• Rebuild with NetSuite configuration or workflow

• Recreate through SuiteScript or SuiteCloud customization

• Retire because the process is no longer needed

This prevents a common ERP mistake: recreating the old system inside the new one.

NetSuite provides strong native capabilities across accounting, approvals, reporting, inventory, purchasing, order management, revenue management, project accounting, and multi-entity operations. Many NAV customizations become unnecessary when NetSuite is configured correctly.

Where custom functionality remains necessary, we design it with maintainability in mind. A clean NetSuite customization supports the process without blocking future releases, integrations, or reporting.

Rebuild integrations with the future operating model in mind

NAV environments often depend on integrations that were added over many years. Some use file imports. Some rely on middleware. Some connect directly to SQL. Some are manual “integration by spreadsheet,” where users export, clean, and upload data between systems.

A NetSuite migration gives us the right moment to redesign the integration landscape.

Typical integration areas include:

• CRM

• Ecommerce platforms

• Expense management

• Payroll and HRIS

• Banking and payments

• Tax automation

• EDI

• Warehouse management

• Shipping and logistics

• Planning and forecasting

• Business intelligence tools

The question is not “how do we reconnect everything exactly as it was?” The better question is “which system owns each process and each data element?”

For example:

NetSuite has a strong integration ecosystem, but strong integration design still requires governance. We define data ownership, sync timing, error handling, field mappings, and exception management before go-live.

If travel and expense processing is part of the future architecture, our guide on how to set up the Navan NetSuite integration gives a practical example of the level of integration detail teams need to consider.

Clean master data before migration

A NAV to NetSuite migration exposes every inconsistency in master data. Duplicate customers, inactive vendors, old item numbers, incomplete addresses, outdated payment terms, and inconsistent naming conventions all slow down testing and weaken reporting after go-live.

We treat master data cleanup as a business activity, not only a technical activity. Finance, operations, sales, purchasing, and warehouse teams need ownership because they understand which records are active, accurate, and relevant.

Priority cleanup areas include:

Customers

• Duplicate records

• Parent-child relationships

• Billing and shipping addresses

• Credit limits

• Payment terms

• Tax settings

• Customer categories and segments

Vendors

• Legal names

• Remittance addresses

• Tax IDs, where applicable

• Payment methods

• Terms

• 1099 or local reporting requirements, where applicable

• Active versus inactive status

Items

• Item types

• Units of measure

• Costing methods

• Preferred vendors

• Inventory locations

• Obsolete SKUs

• Assemblies, kits, and substitutes

Chart of accounts

• Inactive accounts

• Redundant accounts

• Department or cost center embedded in account numbers

• Accounts used as workarounds

• Consolidation mapping

Clean master data makes the entire implementation easier. It improves testing, training, reporting, integration, and user adoption.

We take the same disciplined approach in other ERP migration paths as well, including QuickBooks to NetSuite migration and migrating from Xero to NetSuite. The source system changes, but the principle stays the same: clean data creates a cleaner ERP.

Build a migration plan that matches business complexity

A NAV to NetSuite migration plan should be specific enough to manage, but flexible enough to adapt as decisions are made. We structure migration work into clear phases.

This phase structure keeps the project grounded. It also prevents the team from treating migration as one large event. Good migrations are built through repeatable cycles of extraction, loading, validation, and correction.

Pay special attention to the financial cutover

Financial cutover is where the migration becomes real. The company stops relying on NAV for daily operations and begins transacting in NetSuite.

The financial cutover plan should define:

• Last transaction date in NAV

• Freeze period for master data changes

• Final AR and AP aging extraction

• Open sales order and purchase order migration

• Inventory count or reconciliation approach

• Bank balance validation

• Trial balance extraction

• Foreign currency balance treatment

• Intercompany balance reconciliation

• Approval of opening balances in NetSuite

• First close process in NetSuite

We strongly prefer written cutover checklists with owners, dates, dependencies, and validation steps. Cutover is not the place for informal coordination. Every task needs a name beside it.

The first month-end close after go-live also needs special planning. Teams are learning new screens, new reports, new approval flows, and new reconciliation processes. We plan for that reality and support the closure accordingly.

Validate data through reconciliation, not visual inspection

Data migration is not complete because records appear in NetSuite. It is complete when the business validates that the data is accurate, complete, and usable.

Reconciliation should include:

• Trial balance by entity and period

• AR aging total and customer-level balances

• AP aging total and vendor-level balances

• Inventory quantities by item and location

• Inventory valuation by item and account

• Open sales orders

• Open purchase orders

• Bank balances

• Fixed assets, if in scope

• Historical GL summaries, if migrated

• Customer and vendor record counts

• Item record counts and key fields

We do not rely on spot checks alone. Spot checks help, but reconciliations prove that NetSuite is ready to operate.

Data validation also needs business users. Finance validates financial balances. Operations validates inventory and orders. Purchasing validates vendors and open purchase orders. Sales operations validate customers and open sales activity. ERP migration is a cross-functional business project, not an IT-only task.

Train users around real processes

NetSuite training works best when it follows the way people actually work. Generic system tours are not enough.

Role-based training should cover:

• Daily transaction entry

• Approvals

• Error correction

• Searching and reporting

• Dashboards

• Month-end tasks

• Inventory or warehouse tasks

• Purchasing and receiving

• Order management

• Customer and vendor maintenance

• Escalation paths

We prefer hands-on training with realistic scenarios. A finance user should practice entering and approving a vendor bill, reviewing an aging report, posting a journal entry, and finding supporting detail. A purchasing user should create a purchase order, receive goods, resolve discrepancies, and understand how their actions affect accounting.

Good training reduces post-go-live frustration. It also improves data quality because users understand why fields, approvals, and processes matter.

Avoid the most common NAV to NetSuite migration mistakes

The same mistakes appear across ERP migrations. Knowing them early helps the project team avoid them.

Mistake 1: Recreating NAV inside NetSuite

NetSuite is not NAV in the cloud. It has its own strengths, data model, workflow tools, and reporting structure. Rebuilding every NAV customization without review wastes the opportunity to modernize.

Mistake 2: Migrating too much history

Detailed historical migration sounds useful until it delays testing and complicates reconciliation. Keep NetSuite focused on the future operating model and preserve legacy history through an appropriate archive when that is the better answer.

Mistake 3: Treating data cleanup as optional

Dirty master data creates dirty reporting. Cleanup needs time, ownership, and accountability.

Mistake 4: Underestimating integrations

Integrations drive daily operations. They need design, testing, error handling, and ownership.

Mistake 5: Waiting too long to involve users

Users know the exceptions, shortcuts, and operational realities. Involving them late creates rework.

Mistake 6: Skipping close readiness

The first close in NetSuite is a critical milestone. It needs preparation, not improvisation.

Mistake 7: Making every decision technical

ERP design is business design. Technical feasibility matters, but process ownership, controls, reporting, and adoption matter just as much.

How Versich approaches NAV to NetSuite migration

We approach migration with a practical goal: create a NetSuite environment that finance and operations trust.

That means we focus on clean structure, accurate data, usable reporting, and realistic adoption. We help teams decide what to migrate, what to redesign, what to integrate, and what to leave behind. We also help identify where NetSuite native functionality replaces old customizations and where a tailored solution is still the right choice.

Our work typically includes:

• Current-state NAV review

• NetSuite solution design

• Chart of accounts and segment planning

• Data migration strategy

• Data cleansing guidance

• Migration templates and transformation logic

• NetSuite configuration

• Workflow and approval design

• Integration planning

• Testing support

• Cutover planning

• Post-go-live stabilization

If you are preparing to move from Dynamics NAV or Navision to NetSuite, we recommend starting with a focused migration assessment before the implementation timeline is locked. The earlier we understand your NAV environment, the easier it is to prevent rework. You can reach us through our contact page to discuss the right path for your migration.

Conclusion

A Dynamics NAV / Navision to NetSuite migration is a major opportunity to modernize the business. The value comes from more than moving data. It comes from redesigning the financial structure, cleaning master data, simplifying customizations, improving integrations, strengthening controls, and giving teams real-time visibility in a cloud ERP built for growth.

The best migrations are intentional. They define what NetSuite should accomplish, decide which history truly belongs in the new system, validate data through reconciliation, and train users around real business processes. They do not recreate every old workaround. They build a cleaner operating model.