Dynamics NAV, GP and SL: Why I Think Customers Should Start Planning Now

 

If you are still running Dynamics NAV, Dynamics GP, or Dynamics SL, you have probably heard the conversation about moving to Dynamics 365 Business Central.

The question I hear most often is:

"Do we really need to migrate now?"

My answer is usually: you don't necessarily need to migrate tomorrow, but you should start planning now.

I've spent many years working with Dynamics NAV, Business Central, and data migration projects. One thing I've learned is that the actual migration is rarely the hardest part.

The difficult part is deciding what should be migrated in the first place.

Don't Start With the Deadline

When Microsoft announces lifecycle changes, it is natural to look at the dates and start counting backward.

For NAV, Microsoft says the final version was released in 2017 and extended support ends in January 2028. Microsoft also has separate licensing and service-plan changes coming later, including April 30, 2031. These are different milestones, so I would not treat 2028 as a simple "NAV stops working" deadline.

For me, the more important question is not:

"How long can we continue running NAV or GP?"

It is:

"If Business Central is likely to be our next ERP, what should we be doing today to make that move easier?"

That change in thinking can make a big difference.

Your ERP Has Probably Changed a Lot Over the Years

If you've been running NAV or GP for many years, your current system probably doesn't look anything like the original implementation.

There may be:

• Customizations
• Third-party solutions
• Custom reports
• Integrations
• Historical data
• Business-specific processes
• Workarounds
• Old functionality that nobody remembers why they built

Some of those things may still be critical.

Others may no longer be needed.

And this is where I think migration projects become interesting.

Should we really move all of it?

Probably not.

I've seen situations where people start thinking about migration by creating a list of everything in the existing ERP and asking how to reproduce all of it in Business Central.

I think that's backwards.

I'd rather start with:

What does the business actually need going forward?

Migration Is an Opportunity to Clean Things Up

A migration gives you a rare opportunity to look at the ERP environment with fresh eyes.

For every customization, report, integration, and piece of historical data, I would ask:

Do we still need this?

If the answer is yes:

Does it need to work exactly the same way?

And if the answer is still yes:

Is the existing approach the best way to implement it in Business Central?

That last question is particularly important.

Business Central has a different architecture and extension model from older NAV environments. Microsoft documents supported NAV-to-Business-Central migration paths, but the existing application customizations need to be handled appropriately.

So I wouldn't approach the project as:

"Let's convert everything we have."

I'd approach it as:

"Let's understand what we have, decide what matters, and then determine the best way to build it in Business Central."

Data Is Another Big Question

The same thinking applies to data.

One of the first questions in almost every migration discussion is:

"Can we move all of our historical data?"

Technically, that isn't always the most useful question.

I'd ask:

"What data do our users actually need in Business Central?"

Maybe you need all your history.

Maybe you need master data, open transactions, and opening balances, while older history can remain in another system or reporting environment.

Maybe certain historical transactions are needed for operational reasons, while other data is required only for reporting or audit purposes.

There isn't one answer that works for every customer.

Microsoft's current migration tooling supports different data sets depending on the source system and migration scenario. For example, the GP cloud migration process can migrate setup, master data, transactional data, and historical data, while the specific data to migrate is configurable.

That doesn't mean every customer should migrate everything.

It means there are options.

GP Customers Have Migration Tools, But That Doesn't Mean the Project Is Automatic

For Dynamics GP customers, Microsoft provides built-in cloud migration capabilities for supported GP versions, including GP 2015 and later, subject to the documented prerequisites.

That's good news.

But a migration tool doesn't answer questions such as:

• Which customizations should we replace?
• Which third-party products do we still need?
• Which reports should we rebuild?
• Which integrations need to change?
• How much historical data should we keep?
• How do we validate the financial results?

The technology can help move the data.

The decisions still belong to the project team and the business.

What I Would Do If I Were Starting Today

If I were responsible for a NAV or GP environment today and Business Central was the likely destination, I wouldn't start by scheduling the production migration.

I'd start with an assessment.

I'd want to know:

1. What version are we running?

2. How much customization do we have?

3. What third-party applications are involved?

4. What integrations exist?

5. Which reports are actually being used?

6. How much data do we have?

7. Which historical data do users really need?

8. What business processes depend on custom functionality?

9. What can Business Central handle out of the box?

10. What needs to be redesigned?

Once those questions are answered, the migration strategy becomes much clearer.

Don't Wait Until You Have to Migrate

This is probably my biggest takeaway.

Starting early doesn't mean committing to a go-live date immediately.

It gives you time to:

• Understand the existing environment
• Clean up data
• Review customizations
• Evaluate third-party solutions
• Test migration options
• Identify integration changes
• Run mock migrations
• Validate the results
• Train users
• Make better decisions

Microsoft's own migration guidance emphasizes assessment, preparation, test migrations, data replication, validation, and completion as part of the migration process.

That aligns closely with what I've seen in real projects.

The more you understand before the production cutover, the fewer surprises you are likely to have.

My Takeaway

I don't think NAV, GP, or SL customers should look at Microsoft's lifecycle announcements and immediately panic about migration.

But I also don't think waiting until the last possible moment is a good strategy.

If Business Central is likely to be your next ERP, start understanding your current environment now.

Find out what you have.

Find out what you actually use.

Find out what you really need.

Then decide what should move forward.

Because in my experience, a successful ERP migration isn't about moving everything from the old system into the new one.

It's about moving the right things, leaving behind the unnecessary complexity, and taking the opportunity to build something better.