PODCAST 5: Partner - Customer Story with Rod O'Connor

 


Don’t Panic About Your Integrations:

Moving from Dynamics GP to Business Central

By Cecile Dinh, Microsoft MVP for Dynamics GP & Business Central, with insights from Rod O'Connor of eOne Solutions

In 2018, I had my very first speaking session at Community Summit North America with eOne as my co-presenter.

To this day, I still consider that project one of the most complex integrations I’ve done in my entire ERP career.

And honestly? That experience taught me something important:

Dynamics GP customers should not be afraid of moving to Business Central because of integrations.

A lot of GP users think:

  • “Our integrations are too complicated.”
  • “We have too much automation.”
  • “Our custom scripts will never work in the cloud.”
  • “We summarize millions of records daily.”
  • “We can’t lose our overnight processing.”

I understand those concerns because I lived them.

But here’s the good news:

Most integration concepts from GP can still exist in Business Central — just in a more modern architecture.

This blog is for the GP community we love so much. We want to help customers understand what’s possible and remove the fear around integrations.

The Real-Life Integration Scenario

Here was the challenge we solved years ago in Dynamics GP using SmartConnect and SmartPost.

The Environment

We had:

  • External source database
  • ETL process
  • SQL staging tables
  • SmartConnect integrations
  • Automated posting
  • Intercompany processing
  • Daily automation

And the integration ran almost completely unattended.

The Challenges We Solved

1. Over 1 Million Records Reduced to 35,000 Records Daily

The raw source data was massive.

We summarized over 1 million records into approximately 35,000 transactions daily before sending them into GP.

Why This Mattered

Without summarization:

  • GP performance would suffer
  • Posting would take forever
  • Reporting would become difficult
  • SQL growth would explode

Best Practice

Before integrating into Business Central:

  • Clean and summarize upstream data
  • Reduce unnecessary transaction volume
  • Design integrations intentionally
  • Avoid “dump everything into ERP” mentality

Business Central is powerful, but clean architecture still matters.

2. No Customer or Vendor IDs in the Raw Data

The external system had no GP Customer IDs or Vendor IDs exact match in GP.

I had to translate external identifiers into valid GP records using:

  • SmartConnect translation tables
  • Lookup logic
  • Validation scripts

Example

External Data:

  • Airline Code
  • Agent Number
  • Business Event

Needed to become:

  • Customer ID
  • Vendor ID
  • Document Type

Best Practice

If you’re moving to Business Central:

Do not assume your external systems are “ERP ready.”

You still need:

  • Translation tables
  • Cross-reference logic
  • Data governance
  • Validation layers

In Business Central, this can still be handled through:

  • SmartConnect
  • APIs
  • Azure SQL
  • Power Platform
  • Data transformation layers

3. No GL Accounts in the Raw Data

This was one of the hardest parts.

The source data contained:

  • Transaction IDs
  • Amounts
  • Item Numbers
  • Business Codes

But no accounting entries.

I had to dynamically assign GL Accounts using SQL scripts based on item numbers and business rules.

What We Built

The integration automatically determined:

  • Debit Account
  • Credit Account
  • Intercompany Accounts
  • Revenue Accounts
  • Clearing Accounts

without human intervention.

My Recommendation

Do not hardcode accounting logic everywhere.

Instead:

  • Centralize your mapping logic
  • Maintain account mapping tables
  • Document your business rules
  • Separate accounting logic from raw transaction data

In Business Central, this becomes even more important because you now also have:

  • Dimensions
  • Dimension combinations
  • Intercompany dimensions
  • Analysis reporting

Rod made a very important point during our discussion:

“It’s not just GL accounts anymore. Now you have accounts and dimensions.”

That is exactly right.

4. Intercompany Entries Were Embedded in the Raw Data

This was another major challenge.

The source data already contained transactions affecting multiple companies.

The integration had to:

  • Detect intercompany activity
  • Route transactions correctly
  • Create balancing entries
  • Maintain audit trails

Best Practice

Before moving to Business Central:

Review:

  • Intercompany logic
  • Entity structure
  • Reporting structure
  • Consolidation strategy
  • Dimensions vs company segmentation

Many GP systems evolved over years without redesign.

Business Central is a great opportunity to simplify architecture.

5. Automatic Morning Integration

Every morning around 4:00 AM:

  • Integrations started automatically
  • Transactions flowed into GP
  • Roughly 35,000 records processed
  • Minimal human intervention required

Why Automation Matters

Manual integrations create:

  • Delays
  • Human errors
  • Missed transactions
  • Dependency on key employees

Good News for GP Customers

Automation absolutely still exists in Business Central.

In fact, the cloud architecture can make it even better.

Rod explained that customers can now use:

  • Azure SQL
  • Serverless databases
  • Data Lakes
  • APIs
  • Cloud-based SmartConnect processes

instead of relying only on on-prem SQL servers.

6. Automatic Night Posting

At night:

  • Batches automatically posted
  • Processes ran without interrupting users
  • Financial transactions completed before the next business day

In GP, we used SmartPost heavily.

One challenge with older GP automation was needing active GP sessions running continuously.

Business Central changes this completely.

“What Happens to My Integrations in Business Central?”

This is the biggest question GP customers ask.

And the answer is:

The concepts stay the same.

But the architecture becomes modernized.

Rod explained that Business Central now offers:

  • Standard REST APIs
  • OData APIs
  • Bound Actions
  • Cloud-native integration methods

instead of older GP integration dependency models.

Questions GP Customers Usually Ask

Q: Will I lose my integrations if I move to Business Central?

No.

Most integrations can be redesigned or modernized.

The business logic usually stays.

The technology layer changes.

Q: What happens to my SQL staging tables?

You have options:

  • Azure SQL
  • Serverless SQL
  • Data Lakes
  • Hybrid architecture
  • Existing SQL environments

The answer depends on your environment and strategy.

Q: Can SmartConnect still work?

Yes.

SmartConnect for Business Central supports Business Central integrations.

The approach becomes more API-driven and cloud-focused.

Q: What about automated posting?

Yes — automated posting is still possible in Business Central.

In Dynamics GP, many customers used:

  • SmartPost
  • SQL jobs
  • scheduled GP sessions
  • overnight posting routines

Some GP automation depended on keeping a GP session running continuously on a server.

In Business Central, the architecture becomes more modern and API-driven.

Rod demonstrated how SmartConnect can use:

  • REST APIs
  • Bound Actions
  • scheduled cloud processes

to automatically post:

  • General Journals
  • Sales Invoices
  • Purchase Invoices
  • Credit Memos
  • and other transactions

using Business Central’s native posting routines.

One major advantage is that posting no longer depends on maintaining a continuously running GP desktop session.

That makes the process:

  • cleaner
  • more scalable
  • more cloud-friendly
  • easier to automate securely

The key takeaway for GP customers is this:

Overnight automation and unattended posting are still absolutely achievable in Business Central — but the technology approach is now modernized through APIs and cloud-based services instead of traditional GP session-based automation.

Q: Will integrations become harder?

In many cases, no.

Rod said something important during our conversation:

“The integration layer for Business Central is so much more robust.”

And I agree.

GP integrations often relied heavily on:

  • eConnect
  • Dexterity behaviors
  • SQL dependencies
  • Active GP sessions

Business Central’s API framework is cleaner and more flexible.

My Recommendations as a Solution Architect

1. Don’t Rebuild Bad Processes

Migration is not just technical.

It’s a redesign opportunity.

Ask:

  • Why does this integration exist?
  • Is the logic still needed?
  • Can we simplify it?
  • Can dimensions replace complexity?

2. Document Everything Before Migration

You need:

  • Integration inventory
  • Source systems
  • Frequency
  • Dependencies
  • Posting logic
  • Account logic
  • Translation tables
  • Error handling procedures

Do not rely on tribal knowledge.

 3. Separate Business Rules from Integration Logic

This is one of the biggest recommendations I give to GP customers moving to Business Central.

Over the years, many GP integrations became very complex because business rules were buried inside:

  • SQL scripts
  • Stored procedures
  • SmartConnect scripts
  • Dexterity customizations
  • Hardcoded logic
  • Developer-only knowledge

The integration worked — but only because one or two people understood it.

That becomes risky during migration.

What Do I Mean by “Separate Business Rules”?

Your integration should focus on:

  • Moving data
  • Validating data
  • Triggering processes
  • Calling APIs

Your business rules should live somewhere maintainable and easy to update.

Real Example From My Integration

In our source data, we only had:

  • Transaction ID
  • Item Number
  • Amount
  • Agent
  • Airline
  • Business Event

We did NOT have:

  • GL Accounts
  • Customer IDs
  • Vendor IDs
  • Intercompany Accounts
  • Reporting Dimensions

The integration had to “figure out” everything.

At first, it is tempting to hardcode all logic directly into SQL scripts like this:

IF ItemNumber = 'ABC'
   GLAccount = '4000-00-100'

IF ItemNumber = 'XYZ'
   GLAccount = '5000-00-200'

But over time this becomes dangerous.

Why?

Because every accounting change requires:

  • script updates
  • developer involvement
  • testing risk
  • deployment effort

And eventually nobody fully understands the logic anymore.

Better Approach: Use Maintainable Mapping Tables

Instead of hiding rules inside scripts, create tables like:

Source ItemRevenue AccountDepartmentIntercompany Company
Airline A4100SALESCOMPANY B
Airline B4200OPSCOMPANY C

Now your accounting team or consultants can:

  • review mappings
  • validate logic
  • update rules
  • audit changes

without rewriting integrations.

Keep These Rules Outside the Integration

Accounting Logic

Examples:

  • Revenue account mapping
  • Expense account mapping
  • Clearing accounts
  • Intercompany balancing accounts

Translation Logic

Examples:

  • External customer → BC Customer No.
  • External vendor → BC Vendor No.
  • External item → BC Item No.

Intercompany Rules

Examples:

  • Which company owns the transaction
  • Which entity receives offset entries
  • Elimination rules
  • Consolidation handling

Dimension Mapping

This becomes even more important in Business Central.

Now you must think about:

  • Department
  • Location
  • Project
  • Fund
  • Business Unit
  • Reporting Dimensions

Do not bury dimension logic in scripts.

Maintain it centrally.

Why This Matters in Business Central

Business Central gives companies a chance to redesign processes properly.

This is the perfect time to ask:

“Do we still need this complexity?”

One of the biggest mistakes companies make is moving old integration designs directly into the cloud without rethinking them.

Just because GP processed:

  • 1 million records
  • summarized into 35,000 records

does NOT automatically mean Business Central should receive the same volume.

Challenge the Existing Design

Before rebuilding integrations in Business Central, analyze:

  • Why are we storing this many records?
  • Who actually uses the detail?
  • Is the ERP the right place for all transactional history?
  • Can reporting happen outside ERP?
  • Can data be summarized further?
  • Can Power BI or a Data Lake hold detailed history instead?

This is huge.

Many GP environments accumulated years of historical integration behavior simply because storage and architecture decisions were made long ago.

Business Central migration is the opportunity to simplify.

My Recommendation

Do not automatically recreate old integrations exactly as they exist today.

Instead:

Reevaluate Everything

You may discover:

  • 35,000 records can become 5,000
  • daily detail can become summarized journal entries
  • old intercompany logic is no longer necessary
  • dimensions can replace account complexity
  • reporting can move to Power BI instead of ERP transaction detail

Important Mindset Shift

The goal is NOT:

“How do we move our old integration to Business Central?”

The better question is:

“How should this process work in a modern cloud ERP?”

That mindset changes everything.

And honestly, that is where the real value of Business Central begins.

4. Focus on Data Quality

Clean Data = Clean Go-Live.

Always.

Bad source data becomes worse in the cloud if governance is ignored.

5. Test Automation Early

Do not wait until go-live week.

Test:

  • Scheduling
  • Posting
  • Error handling
  • Recovery scenarios
  • Performance
  • Intercompany balancing
  • Permissions
  • API limits

early in the project.

Final Thoughts

If you are a GP customer nervous about integrations, I want you to hear this clearly:

Complex integrations do not automatically block your move to Business Central.

I’ve worked on integrations involving:

  • millions of records
  • automated posting
  • translation tables
  • intercompany processing
  • dynamic GL generation
  • overnight automation

And those concepts can absolutely continue in Business Central.

The tools are different.

The architecture is modernized.

But the possibilities are still there.

That’s why we continue sharing these experiences with the community.

Because someone out there is probably asking the same questions you are asking today.

And we want you to know:

You are not alone in this journey.

Special thanks to Rod Connor from eOne Solutions for sharing his insights and helping the GP community feel more comfortable about the transition to Business Central.



Comments

Post a Comment

Popular posts from this blog

PODCAST 3: Partner Story with Shannon Mullins, MVP

Image
  Shannon’s journey began as an end user moving from QuickBooks to Great Plains at a mortgage company—right as Microsoft acquired GP. Years later, she was tapped to start a cloud practice and self‑learned NAV/BC.  Today she’s the  CEO of BC Consulting Group , a  7x Microsoft MVP , and remains hands‑on: guiding training, testing, and solution design while her team handles administration and data migration   “I’ve built a strong team with real end‑user experience. I stay involved in design, training, and testing so projects stay practical and successful.” Quick Summary Shannon Mullins shares her 25‑year journey from Great Plains (GP) to Microsoft Dynamics 365 Business Central (BC)—from her first implementation as an end user to leading a BC consulting practice. We dig into common misconceptions, the real work behind migrations, why discovery matters, and the game‑changing impact of Power Platform. If you’re GP‑curious or mid‑migration, this episode is a practical,...
Read more

PODCAST 2: Partner Story with Kristen Hosman, MVP

Image
  From GP End User to Business Central Consultant Kristen’s journey started 20 years ago as an accounts payable clerk at a casino. She quickly became fascinated with GP as a full ERP, asking questions beyond her role: “How does purchasing work? What happens when there’s a margin difference?” That curiosity led her into GP consulting and eventually into Business Central, just as Microsoft began signaling the shift toward the cloud. As Kristen put it, “I didn’t want to be a GP consultant forever. I wanted to learn something new, and Business Central was the future.” Running a Consulting Firm While Staying Hands-On Today, Kristen leads Mount Evans Consulting , a small but growing firm. Despite being a six-time MVP and business owner, she remains hands-on: Managing implementations Supporting clients directly Training users Growing her team Her motivation is clear: “At the end of the day, it’s my name. If my clients aren’t happy, that’s on me.” The Realities of GP...
Read more

PODCAST 4: Partner Story with Amber Bell, MVP

Image
Amber Bell is the CEO of Training Dynamo, LLC and a long-time leader in the Microsoft Dynamics community. She brings over two decades of hands-on experience with Dynamics GP and now Business Central, helping organizations improve data quality, processes, and user adoption. Amber is known for her practical, people-first approach. She specializes in GP implementation, GP to Business Central readiness, training, documentation, and guiding teams through change with clarity and confidence. As a Microsoft MVP and frequent speaker at industry events, she’s passionate about knowledge sharing, community building, and helping both consultants and end users succeed. Her strength lies in bridging the gap between technology and people—making complex systems easier to understand, easier to use, and easier to trust. Below is a timestamped summary of our podcast interview. 00:00 – Community and Knowledge Sharing Topic: Why community matters Amber opens by talking about how much she enjoys seeing f...
Read more