NAV/BC to F&O Migration Training

aka System Transplant

Migrating from NAV/BC to F&O? This isn’t just a facelift—it’s a full transplant. Our toolkit walks you through it without the cold sweats.

Training Clinic Tools

Table of Content

NAV-BC to FO Migration Training Cover

Get Free eBook

Join the clinic rounds — we’ll send you expert-approved remedies straight to your inbox.

NAV/BC to F&O Migration Training

aka System Transplant

Migrating from Dynamics NAV or Business Central (BC) to Finance & Operations (F&O) is more than just a lift-and-shift — it’s a full-blown clinical procedure. You’re not just swapping out systems; you’re transitioning to an entirely new anatomy of enterprise operations. Without the right planning (and a bit of bedside training), the project can quickly flatline.

This guide is your surgical roadmap — with a dose of humor — to help training teams, project managers, and functional leads think through the right learning interventions, exactly when and where they’re needed.

 

Workstreams: The Organs of Migrations

Every successful ERP migration depends on the health of a few vital systems — and in this case, we call them workstreams. These are the mission-critical subsystems that keep the implementation breathing from day one to go-live (and beyond). Neglect one, and your project could flatline.

Let’s review the core five:

  • Configuration: System setups, parameters, workflows — all the knobs and dials that keep daily operations flowing. It’s the baseline blood pressure of your ERP.
  • ISV Solution: Third-party apps and add-ons that need to be ported, replaced, or re-licensed. Think of these as prosthetics — useful, but needing custom fitting.
  • Customization: Anything that’s coded, extended, or modified — usually the most invasive surgeries. One wrong move, and you’re in recovery mode for weeks.
  • Migration: Moving data from NAV/BC to F&O — sometimes more like untangling DNA than copying files. This is your ERP’s memory transplant.
  • Integration: The connective tissue that links your ERP with CRMs, banks, logistics tools, and more. When it works, it’s seamless. When it doesn’t… you’ll know.

Each workstream requires attention across every phase of the project — and smart training strategies are the oxygen masks that keep both teams and timelines from gasping.

 

Introducing Migration Factors:

When migrating from NAV or BC to F&O, some symptoms are easy to spot — delays, rework, or teams frantically paging each other for help. But just like in medicine, the real issues often lie beneath the surface. That’s where Migration Factors come in.

Think of these as the vital signs of your ERP migration — deep indicators that reveal how intense the change will be, and where the complications might arise. If even one is out of balance, the entire project starts to feel under the weather.

Here’s your pre-op checklist:

Terminology

This is your system’s vocabulary. If “vendors” suddenly become “suppliers” or “sales orders” turn into “customer confirmations,” expect some puzzled glances and miscommunication. Everyone may sound confident — but they’re not talking about the same thing. That’s a recipe for errors and escalations.

Interface

This is how your users get around. Buttons, menus, screens — the bedside manner of your ERP. If it shifts too much, users will fumble like interns in their first night shift. Familiar features disappear, new ones look suspicious, and nobody knows where the stethoscope went.

Functionality

These are your system’s core capabilities. When features are added, removed, or radically transformed, users may feel like they’re on a new medication without the dosage guide. Some rejoice, some resist, and everyone wonders how to get back to their old routine.

Data Model

This is the internal anatomy — how tables, fields, and relationships are structured. A new model means new mappings, reworked reports, and lots of post-op therapy for your integrations. Skip this analysis, and your clean migration might develop some nasty side effects.

Platform

This is the surgical suite — the environment your system runs on. Moving from on-prem NAV to cloud F&O isn’t just a relocation, it’s a transplant. Your scripts won’t work the same, your tools might be different, and the infrastructure will definitely need new care instructions.

 

Meet the Migration Anatomy Chart

Now that we’ve examined the core workstreams and diagnosed the key migration factors, it’s time to bring it all together.

This is The Migration Anatomy Chart — your high-level scan of what happens when NAV or BC is prepped for a full-on ERP transplant to F&O. In this chart, the five migration factors (Terminology, Interface, Functionality, Data Model, Platform) represent the internal systems of your legacy ERP. These are the elements most likely to get disrupted, inflamed, or completely replaced during the procedure.

Surrounding them are the five workstreams (Configuration, ISV Solution, Customization, Migration, Integration) — the critical operations that happen throughout the project. These workstreams are where the pain shows up first when a migration factor is misunderstood, misaligned, or skipped over entirely.

In short:

The inner circle is the “why it matters.” The outer circle is “where it hurts.”

Now, let’s examine each factor — one by one — and trace how they impact each project workstream. Grab your stethoscope, because it’s time to go deeper into the anatomy of smarter migration.

NAV/BC to FO Migration Anatomy Chart

Migration Factor #1: Terminology

Translation Trouble Starts Here 🗣️ Terminology is often the silent saboteur of ERP migrations — and when shifting from NAV or BC to Finance & Operations (F&O), the language barrier is real. What might’ve been a simple “dimension” or “customer card” in BC transforms into an intricate web of financial hierarchies, legal entities, and party records in F&O. This isn’t just a change in vocabulary — it’s a shift to a more granular, layered, and standardized language of enterprise operations. And if your team’s still speaking “BC,” your migration will sound like a game of ERP telephone. Real Examples of Terminology Gaps
  • In BC, a “Location” is just a simple storage spot. In F&O, it’s part of a full vocabulary hierarchy: Site → Warehouse → Aisle → Location. Same word, but now with a lot more directional signs.
  • The term “Dimensions” takes on a whole new life in F&O. While BC sticks with two Global Dimensions and a few Shortcut ones, F&O offers a full house: Financial Dimensions, Product Dimensions (like Color, Size, Style), Storage Dimensions (like Site and Warehouse), and more — each meaning something different and used in different contexts.
  • A plain “Item” in BC splits into multiple terms in F&O — Product, Product Master, Variant, Released Product. Without clarification, users might think these are separate records instead of flavors of the same concept.
  • The friendly “Customer” and “Vendor” records in BC become more formal in F&O: Customer Account, Vendor Account, and the umbrella Party The language upgrade sounds fancier — but without training, it’s also more confusing.
These aren’t just dictionary differences — they show up in every workstream like so:
Workstream Impact of Terminology Differences
Configuration Misunderstood terms cause incorrect setup of key elements like sites, dimensions, and product categories.
ISV Solution Terminology mismatches may lead to deploying unnecessary ISV solutions to fill perceived functionality gaps.
Customization Developers may hardcode old field names or logic that no longer applies, increasing rework.
Migration Terminology confusion complicates mapping legacy data fields to new F&O structures.
Integration Misaligned terms cause integration logic errors, especially when matching entities across systems.
How Training Helps: Early-stage training that clearly explains F&O terminology — especially when mapped to NAV/BC equivalents — prevents weeks of confusion and costly design rework. It helps align language across teams, reduces friction in configuration workshops, and sets shared expectations before decisions get locked in. When users and consultants speak the same ERP language from the start, every workstream benefits — from cleaner setups to smarter integrations. Most importantly, it builds confidence in the new system’s structure, so your team isn’t learning by trial and (very expensive) error.

Migration Factor #2: Interface

Looks Familiar — Until It Doesn’t 🖥️ At first glance, the user interfaces of Business Central (BC) and Finance & Operations (F&O) can seem like siblings — clean, modern, and fully cloud-based. But don’t let that shared Microsoft DNA fool you. While both are web-based and leverage similar styling, they differ significantly in depth, layout, and user experience. For those coming from legacy NAV systems, the leap is especially jarring. BC introduces a more modern look, but F&O takes things several steps further. It relies on workspaces, tiles, action panes, and filter panes to organize complex data — along with power-user tools like saved views, personalization, and workspace pinning. Where the differences become most pronounced is in how users navigate, filter, and interact with data:
  • F&O’s grid filtering, advanced query syntax, and workspace navigation allow slicing and dicing of data in highly configurable ways.
  • Common actions like opening related data, jumping between records, or viewing audit history require new navigation habits.
  • Pop-outs, form controls, and side panels behave differently — more powerful, but also more click-intensive.
Workstream Impact of Interface Differences
Configuration Misuse or misunderstanding of UI elements (e.g., filters, form panes) can result in incorrect or missed setup steps.
ISV Solution Users may struggle to access embedded features or misunderstand how third-party solutions fit within the F&O interface.
Customization Change requests may arise simply from unfamiliarity — not system limitations. Customizations may be incorrectly requested to mimic legacy interfaces.
Migration Data review and validation processes can slow down if users can’t easily navigate or compare records.
Integration Integration errors may be misinterpreted due to differences in how data is surfaced or logged in the UI.
How Training Helps: Effective interface training prevents frustration and delays by showing users how to navigate, filter, and personalize the system as designed. It minimizes unnecessary customizations by helping users adjust to F&O’s native interface rather than reshaping it to resemble their previous system. Confident users are less likely to open support tickets for things that are already there — just a few clicks away.

Migration Factor #3: Functionality

More Than Just a Feature Upgrade 🧩 If Interface is how users interact with the system, Functionality is what the system actually lets them do — and this is where Finance & Operations (F&O) really spreads its wings. Compared to Business Central or NAV, F&O isn’t just deeper in individual modules — it opens doors to entirely new business domains. In many NAV/BC environments, these capabilities either didn’t exist or required heavy customization or third-party ISVs. Here are just a few examples of where F&O expands the functional frontier:
  • Advanced Warehouse Management– with wave picking, license plates, and handheld device support
  • Engineering Change Management– for controlled product versioning and release processes
  • Process Manufacturing– support for formulas, co/by-products, and batch orders
  • Rebate Management– trade allowances and incentive-based pricing
  • Asset Management– planned maintenance, condition monitoring, and work orders
  • Project Operations– resource-based billing, planning, and execution
  • Demand Forecasting & Master Planning– predictive supply chain tools
  • And more– Transportation Management, Retail & Commerce, Credit & Collections, Time & Expense, and more
This expanded scope influences multiple areas of the project:
Workstream Impact of Functionality Differences
Configuration Requires additional planning to activate and define how rich standard features should behave across entities and roles.
ISV Solution Many prior ISVs become redundant or optional due to built-in capabilities in F&O, changing selection and budgeting.
Customization Custom code becomes unnecessary when out-of-the-box functionality covers key business needs — if the team knows it’s there.
Migration Legacy processes or data structures may need remapping to align with expanded features and new modules.
Integration New modules introduce additional integration points and more complex flows between F&O and external systems.
How Training Helps: When project teams understand the native capabilities of F&O early on, they can reduce the impulse to rebuild or overcustomize. Functional training helps align expectations, minimize ISV bloat, and let the system do more of the heavy lifting as designed. It ensures you don’t spend time re-creating what F&O already does out-of-the-box — you just need to know it’s there.

Migration Factor #4: Data Model

It’s Not Just Tables Anymore 🧬 The data model is the circulatory system of any ERP — and in a move from BC/NAV to F&O, it’s often the most underestimated change. While Business Central has a flatter, more familiar table structure rooted in its NAV heritage, F&O is built with a highly normalized, layered, and segmented data model that supports complex business scenarios across legal entities, geographies, and operations. That shift doesn’t just add columns — it changes how data flows, connects, and gets consumed by everything from reports to workflows to third-party systems. Financial dimensions, reference tables, virtual entities, and party-based data models (like global addresses or centralized customers) can be jarring to teams used to simpler schemas. And here’s the kicker: this affects everything.
Workstream Impact of Data Model Differences
Configuration Requires new understanding of data relationships, hierarchies, defaulting rules, and dimension combinations.
ISV Solution Add-ons must be revalidated for compatibility with F&O’s schema and naming conventions.
Customization Custom forms, reports, and extensions must account for relational depth — or risk breaking badly.
Migration Mapping and transforming legacy data into F&O’s structure becomes a project in itself.
Integration APIs and data feeds require adjustments for entity logic, surrogate keys, and dependency chains.
How Training Helps: Understanding F&O’s data model isn’t just for developers. Functional leads, power users, and report builders all benefit from learning how data is structured and flows. Training reduces rework, avoids faulty assumptions, and ensures project teams are building on a solid, well-understood foundation.

Migration Factor #5: Platform

The ERP Operating Room Has Upgraded 🏥 If the data model is the circulatory system of your ERP, then the platform is the operating room it all takes place in. And in the case of migrating to F&O, the room has changed — the lighting is brighter, the tools are sharper, and the procedures are far more regulated. Finance & Operations operates on a modern cloud-first platform with architectural concepts that may be completely foreign to NAV/BC veterans. This includes:
  • Lifecycle Services (LCS)– for environment management, issue tracking, and deployment pipelines
  • Azure DevOps– for source control, build automation, and release management
  • Data Entities and OData– replacing direct SQL access and enabling structured integration
  • Extension model– a layered, safe way to customize without touching core code
  • Telemetry and Monitoring– real-time system diagnostics and usage tracking
Unlike BC/NAV, where developers often had more control (and more risk), F&O enforces guardrails and structured processes that require new skills and expectations. This has massive implications for the more technical workstreams:
Workstream Impact of Platform Differences
Configuration More structured environments mean setup happens in managed tiers with formal ALM controls.
ISV Solution ISVs must be validated against platform requirements, APIs, and deployment methods.
Customization Development requires working within extension layers, using DevOps pipelines, and adhering to strict coding standards.
Migration Must leverage Data Management Framework (DIXF), staging tables, and batch jobs with care.
Integration Integrations rely on OData, custom services, and APIs rather than direct database access.
How Training Helps: Platform-specific training gives technical teams the foundation they need to adapt their old habits to the new F&O reality. It prevents missteps in architecture, improves collaboration between developers and functional teams, and ensures smoother deployments with fewer band-aid fixes.

Final Diagnosis: Training is Your Wellness Plan

Migrating from NAV or BC to F&O isn’t just a software upgrade — it’s like transferring your care from a cozy family clinic to a cutting-edge specialist hospital. Everything runs deeper, looks cleaner, and has a lot more buttons… but without the right prep, it’s easy to feel like you’ve been wheeled into the wrong ward. Each migration factor we’ve explored — from terminology shakeups to platform overhauls — opens doors to powerful new capabilities… and a few bewildered looks. Even seasoned teams can wind up reinventing the wheel (or worse, customizing it) if they don’t understand what’s already in the toolkit. That’s where training steps in — not as a dry lecture, but as your scrubs-wearing, clipboard-carrying guide to system sanity. Think of training as:
  • Your translator when the new terminology starts sounding like medical Latin
  • Your walking tour through a brand-new interface (with snack breaks!)
  • Your “what not to customize” checklist, saving time, budget, and nerves
  • Your wellness plan — proactive, confidence-boosting, and good for everyone involved
Training isn’t just how you survive go-live. It’s how you thrive beyond it — with fewer support tickets, cleaner configurations, and happier users all around. So before you reach for that customization scalpel or send another SOS to the dev team, take a deep breath and schedule some training. Your system — and your stakeholders — will thank you.