Why Your Business Central Won't Scale to Finance & Operations

six years on Business Central, clean data, solid reporting, finance team that actually trusts the numbers. Then the acquisition happens and someone on the leadership team says the line you've probably heard before will move to finance and operations eventually, eventually never comes. Not because nobody wants to do it, because there's no path to work. Most IT leaders picture Business Central and Finance and Operations sitting on the same ladder, one rung apart, outgrow one, climb to the next, that picture is wrong. The reason there's no upgrade button isn't a licensing restriction Microsoft could lift with a policy change. It's structural, it's buried in the data model itself, in how each system was built and who it was built for. By the end of this, you'll know exactly where that wall sits. You'll know why merges and acquisitions hit it harder than almost anything else, and you'll know what to build instead of waiting for a bridge that was never designed to exist. Welcome back to M365FM. If you haven't hit subscribe yet, do that now because we get into the parts of the Microsoft ecosystem that don't show up in the sales deck. Today, we're breaking down the Business Central to finance and operations trap. It's a trap because it catches growing companies exactly when they can at least afford a surprise, usually mid acquisition, usually with a board waiting on numbers. Let's get into why this even becomes a question in the first place. Why this question even comes up? Business Central gets sold with a specific promise baked into the pitch. Start here, grow into anything. Essentials for the basics, premium ones you need manufacturing or service management, and finance and operations waiting somewhere down the road once you're ready. It reads like a ladder, step one, step two, step three, and the top step is enterprise scale. Streaming isn't malicious, but it's misleading. And here's why. Business Central and finance and operations were never the same product stretched across company sizes. They're two separate systems with two separate lineages, and that distinction matters more than almost anything else in this conversation. Business Central comes from Dynamics Nav. Finance and operations comes from Dynamics AX. Different code bases built in different countries designed in different decades for different problems. Nav was built for speed and simplicity in smaller operations. AX was built from the start for organizations with global footprints and financial complexity that Nav was never asked to handle. Microsoft didn't take one product and split it into a small version and a big version. It kept two products with different DNA and marketed them under one umbrella. So here's what actually happens on the ground. The company runs Business Central for years, everything works, and then someone in a strategy meeting starts talking about acquisitions or a second country or consolidating financials across multiple entities. And almost on cue somebody says it. It'll just upgrade to F&O later. That sentence is the trap. It sounds like a plan. It sounds like the kind of thing you write into a three year road map slide and move on, but it assumes a bridge exists between these two systems that simply isn't there. It assumes upgrade means what it meant when nave moved to business central. Same lineage, same logic, data carrying forward with some conversion work. Business Central to finance and operations doesn't work that way, and understanding exactly why is where we're headed next. The assumption that breaks. Here's the model most people carry around in their head without ever questioning it. ERP is a single track. You start small, you outgrow the system, you step up to the bigger one. It's the same logic as moving from a starter apartment to a house, more space, same neighborhood, same city, just bigger rooms. That model works fine for some transitions. It does not work here, and the reason it doesn't work is worth naming directly instead of hinting at. People assume upgrade means moving data forward the same way it moved when nave became Business Central, same tables mostly, same posting logic mostly. A conversion tool does the heavy lifting, extensions replace old customizations, and six months later you're running a newer version of the same underlying system with a better interface and cloud hosting. That's what an upgrade looks like when it's real. Business central to finance and operations isn't that. It's not a newer version of the same thing, it's a full re-implementation, and those two words carry very different weight once you understand what's actually different underneath. The technical architecture is different. The data model is different, the posting logic is different, these aren't surface level differences you patch with a mapping document. A general ledger entry in Business Central doesn't sit in the same table structure as a general ledger entry in finance and operations. Dimensions work differently. Posting groups don't translate one to one. Even something as basic as how a transaction gets tagged to a legal entity follows different rules in each system because each system was built around a different assumption of how many legal entities exist and how they relate to each other. So what does re-implementation actually mean once you strip the label off? It means extraction. Using data out of Business Central in a format that means something outside of Business Central's own internal logic. It means transformation, reshaping that data to fit a completely different schema. One built for a different scale of complexity. It means loading. Pushing that transformed data into finance and operations using its own data management tools. Tools that assume you're bringing in enterprise grade structure, not small business simplicity. And it means validation. Checking, line by line, account by account, that what landed on the other side actually matches what left the original system. Each of those four steps is a project, not a checkbox on a project plan, not a week and task for an integration specialist, a project with its own risks, its own timeline, its own places where things go wrong. Here's where the real damage happens. And it's not technical, it's financial. Companies sit down, look at what NAFTA BC Migrations cost, look at what BC to BC version upgrades cost, and they budget for something in that range. A migration. A few months, a defined scope, a partner quote that feels proportional to moving to a new system. Then the actual project starts and it behaves like what it actually is. A full implementation, at implementation cost on an implementation timeline. The budget that felt reasonable in the boardroom is suddenly short by a wide margin and the timeline that got promised to the board is suddenly off by months, sometimes longer. To understand why no bridge exists to soften any of this, you have to look at what these two systems were actually built to do in the first place and who they were built to serve. What business central was actually built for? What was built with who business central was designed for? Because that answers almost every question about why it behaves the way it does. One entity or a small handful of connected ones. One country or a few. One finance team that knows every account by heart because there aren't thousands of them to memorize. That target shapes everything. Implementation runs three to six months because the software doesn't ask you to make a thousand configuration decisions before you can post a single invoice. The cost per user stays low because the system isn't carrying the weight of features, a small business will never touch. One of the central ships with an assumption baked in. Most companies using this don't want to configure a general ledger from scratch. They want one that already works and lets them tweak the edges. That's the core design philosophy stated plainly. Simplicity is the default state. Complexity is the exception you bolt on when you actually need it. Not the baseline you wade through just to get started. Look at who's actually sitting in front of this software all day. Finance teams closing the books for one company, maybe two. These managers tracking inventory across a single warehouse or a small regional network. Procurement staff running purchase orders through a straightforward approval chain. Small manufacturing shops assembling discrete products on a production floor they can walk across in five minutes. None of these users are managing global tax jurisdictions or reconciling six currencies against the central treasury function. They're running a business and the software gets out of the way so they can do that. Now look under the hood because this is where the design philosophy becomes structural rather than just a feeling. The tables in business central that dimensions the posting groups all of it gets built around the idea of one company or a small set of companies that talk to each other in fairly simple ways. A dimension in business central tracks something like department or region sure but it's not architected to carry the weight of multi entity elimination logic across a dozen legal structures in a dozen countries. It was never asked to. This is the point worth sitting with before moving on. Business central isn't a smaller version of finance and operations with some menu items grade out. It's not F&O with the enterprise features hidden behind a paywall. It's a separate design philosophy from the ground up built around a different question entirely. F&O's architects asked how do we handle enterprise complexity at scale business central's architects asked. How do we get a growing company running in weeks instead of months without making them think about problems they don't have yet two different questions produce two different systems. And once you see it that way the next question answers itself what happens when you ask the same architecture to solve the other question instead. What finance and operations was actually built for? Flip the question around and you get finance and operations where business central starts from one entity and a small footprint F&O starts from the opposite assumption entirely. Large enterprise multiple legal entities multiple countries and consolidation that has to happen automatically not manually because doing it by hand at that scale simply isn't possible. That starting assumption shows up in the numbers before you even open the software implementation runs six to 18 months not because the vendors are slower or the consultants less capable but because the system asks you to make enterprise level decisions before you can post your first transaction. Cost per user runs higher for the same reason and the defaults aren't opinionated the way business central's are. F&O gives you deep configurability instead because a system built for a thousand different enterprise shapes can't afford to guess what any one of them needs out of the box. Here's the mindset shift that matters most. Business central treats complexity as the exception you add when you need it. F&O treats complexity as the default state you're managing from day one multiple currencies aren't a feature you turn on they're assumed automated eliminations aren't a nice to have they're built into how the system expects consolidated entities to behave advanced manufacturing scenarios global tax jurisdictions with their own filing requirements layered approval chains across regions none of that is bolted on afterward it's baked into the architecture from the first table design decision one number tells you everything about who the system was built for and it's worth sitting with for a second finance and operations has a minimum of 20 users business central has a minimum of one that gap isn't a licensing quirk somebody said arbitrarily it's a signal about scale nobody builds a 20 user floor into a system meant for a five person finance team you build that floor when you're designing for organizations where 20 users is already the smaller end of the range consolidation is where this becomes concrete rather than abstract in F&O consolidation isn't something you configure with a work around or a third party add on its native the system expects multiple entities to exist expects them to transact with each other and expects finance teams to need a single consolidated view without manually reconciling five sets of books by hand every month and that's not a premium feature sitting behind an upsell it's part of what F&O assumes you need the moment you open it because the organizations it was designed for never operated any other way so here's the point worth carrying forward finance and operations isn't business central with more toggles switched on it isn't the same chassis with a bigger engine dropped in it's a different chassis altogether built from the ground up to carry enterprise weight the same way F&O's ancestor dynamics ax was built for organizations that never fit inside navs design in the first place two systems two different questions answered from the ground up and that difference stays invisible completely invisible right up until growth forces the question which is exactly where the next part of the story starts the moment growth exposes the gap most companies never feel this wall directly they run business central for years everything working the way it's supposed to and the architecture question sits dormant because nothing ever forces it awake then one event changes that almost always it's an acquisition here's how it actually plays out a company runs business central happily closes its books on time finance trusts the numbers then it acquires another company or gets acquired itself or opens up in a second country to chase gross leadership signed off on 18 months ago overnight there isn't one business central instance anymore there are two sometimes three each one running its own version of the truth its own chart of accounts its own definitions baked into its own database with nobody outside that entity able to see inside it cleanly leadership once what leadership always wants in this moment one unified view of the business a single number for revenue a single number for margin something a CFO can put in front of a board without a footnote explaining why the number depends on which system you're looking at and that's exactly where the obstacle shows up immediate and structural business central wasn't built to consolidate across separate instances natively it was built around the assumption of one entity or a handful of entities living inside one connected environment to stand alone business central databases each with its own posting logic don't talk to each other by default there's no button that merges them into a single reporting layer the consolidation business central offers assumes you're already inside one house it doesn't assume you're trying to merge to separate houses built on different foundations the stakes here aren't abstract without real consolidation financial close stops being a matter of days and turns into a matter of weeks someone on the finance team is pulling numbers out of one system someone else is pulling numbers out of the other and both sets land in a spreadsheet where a human being reconciles them by hand under deadline pressure every single month errors creep in exactly where you'd expect map to counts the don't line up currency conversions handled slightly differently in each instance timing differences nobody catches until an auditor asks about them and once the board starts noticing that the numbers shift between the first draft and the final version trust erodes fast nobody signs off on a set of financials they've watched change three times in a week this is usually the exact moment somebody says the sentence out loud for the first time not in a planning session not on a road map slide months in advance in a tense meeting after a close that ran two weeks too long someone says let's just move to finance and operations it sounds like relief it sounds like the obvious next step after watching to business central instances refused to talk to each other cleanly what that sentence doesn't account for yet and what the rest of this breaks down is what actually sits between where that company is standing and where finance and operations lives why M&A is the real trigger an acquisition explains why the wall shows up it doesn't explain why the wall gets so much worse so fast for that look at private equity roll ups because they compress years of organic growth pain into a single deal cycle here's the pattern affirm buys five small companies inside 18 months folding them into one portfolio company with one board and one set of investors expecting one clean set of financials each of those five companies already runs its own ERP before the ink dries on the acquisition several of them run business central because business central is exactly the kind of system a company that size would have chosen five years earlier the obstacle doesn't add up in a straight line it multiplies five separate charts of accounts none of them built with the others in mind five separate data models each shaped by whichever consultant configured it years ago for a company that had no idea it would eventually get acquired five different working definitions of something as basic as customer because one entity tracks billing contacts separately from shipping contacts and another doesn't bother making that distinction at all none of this is a technical hiccup it's five independent decisions made independently now expected to collapse into one number on a board slide inter company elimination is where this stops being theoretical and starts costing real money as we saw earlier f and o treats consolidation as native what that native module doesn't do is reach outside its own walls into an external business central system it has no visibility into f and o's elimination logic was built to handle transactions between entities that already live inside f and o's architecture a business central subsidiary sitting outside that architecture isn't part of the conversation the elimination module is designed to have so the moment leadership needs one true consolidated number custom logic stops being optional and becomes mandatory somebody has to build the bridge that identifies which transactions in bc correspond to which transactions in f and o match them flag them and zero them out before anyone reports a combined figure to the board that's not a checkbox in the settings menu that's a project built and maintained by someone indefinitely for as long as the patchwork stays in place there's a threshold where this math actually flips and it's worth naming as a number rather than a feeling once an organization is running more than three separate business central instances feeding into one consolidation effort or once intercompany transactions climb past roughly 30% of total bc general ledger volume the cost of holding the patchwork together starts outpacing the cost of just migrating outright below that line custom integration is annoying but survivable above it every acquisition adds another layer of reconciliation work another set of mappings another place for something to quietly break during close that's the real trigger hiding behind we made an acquisition it's not the acquisition itself it's what acquisitions due to the math compounding a manageable integration problem into one that costs more to maintain than to replace which raises the obvious next question what does that patchwork actually look like while a company is still holding it together month after month close after close inside the patchwork data verse and dual write start with data verse because everything else in this section depends on getting that piece right data verse is a shared data layer think of it as a common storage space that different Microsoft business apps can write to and read from so a customer record created in one app can show up in another without somebody manually retyping it sales customer service business central finance and operations they can all point at the same underlying data instead of keeping five separate copies that drift apart over time that's the concept now here's where most explanations of this go wrong and where the confusion actually starts costing companies money dual write is a specific piece of Microsoft's integration plumbing and it does something real near real time two way sink built specifically to connect finance and operations with customer engagement apps like sales change a customer's payment terms in FNO and that change shows up in sales within seconds not hours that's genuinely useful and it's genuinely well built here's the correction that matters the one that trips up almost every it leader looking at this from the outside dual write was not built for business central business central runs its own separate data verse sink mechanism a different piece of engineering entirely doing a similar job but through a completely different pipe so what does that actually mean once you're running BC in your subsidiaries in FNO at headquarters it means there is no single dual write map spanning both systems none you're not flipping one switch and watching data flow cleanly between BC and FNO through one unified integration layer you're stitching together two separate integration systems that were never designed to talk to each other in the first place one built for FNOs world and one build for BCs and then building the connective tissue between them yourself that distinction sounds technical until you hit the part that actually changes how your business runs day to day timing BC's data verse sink jobs run on a schedule not in real time default configuration checks every 30 minutes if nothing's changed the drop can go quiet for up to 12 hours before it checks again for a single company running one business central instance with nobody outside that instance waiting on the data that delay doesn't matter nobody's checking a dashboard every 90 seconds waiting for a customer record to refresh change the picture to a subsidiary running BC while headquarters runs FNO and that same 30-minute to 12-hour window turns into a liability finance can actually feel headquarters need same-day numbers from a subsidiary closing out a busy sales day instead they're looking at whatever synced last which might be current or might be sitting 12 hours stale depending on when the last change happened to trigger the job nobody planned for that gap it just showed up baked into the default behavior of a sync mechanism most people assumed worked like the near real time dual right they'd heard about somewhere else here's the point worth sitting with before moving forward from a distance all of this looks like integration data moves between systems dashboards populate reports pull numbers from more than one source it looks clean on a slide look closer and what you actually find is two different plumbing systems each build for a different product each running on its own schedule with its own assumptions connected at the joints by whatever custom work somebody had to build to bridge the gap Microsoft never closed that's not integration in the sense most leadership teams picture when they hear the word it's duct tape applied carefully holding two systems together that were never meant to share a pipeline the one way street how GL data actually moves strip away the terminology and here's what actually happens with the money general ledger data moves in one direction from business central up to finance and operations not both ways not a living breathing sync where either system can update the other one direction BC to FNO full stop and it doesn't move continuously it moves on a schedule a batch job that runs daily or weekly depending on how somebody configured it pulling a defined set of transactions out of BC and pushing them into FNO's consolidation layer that's the mechanism nobody's watching a live feed of subsidiary transactions landing at headquarters the instant they post here's what that actually means for the people staring at a dashboard headquarters running FNO is looking at yesterday's numbers from the subsidiary not this morning's numbers not right now numbers whatever batch job ran last on whatever scheduled somebody said months ago usually overnight sometimes less often than that if the subsidiary closed a major sale at four in the afternoon headquarters isn't seeing it reflected in consolidated figures until the next batch cycle runs and depending on the schedule that might not be until the following day during a normal month that lag is an inconvenience during month and close it compounds into something worse reconciliation happens against data that's already a day or two stale by the time anyone's looking at it someone at headquarters flags a discrepancy someone at the subsidiary investigates and by the time the answer comes back another batch cycle has already run and shifted the numbers again corrections happen after the fact layered on top of numbers that were already layered on top of the numbers before them close doesn't get faster with more systems in play it gets slower one batch job at a time now put that against what gets promised somewhere in a sales conversation months before any of this integration work starts real time visibility across the business one dashboard current numbers leadership making decisions of what's actually happening right now instead of what happened yesterday that promise isn't a lie exactly it's just built on an assumption that never gets stated out loud it assumes one system it assumes everyone's data lives in the same database updating the same tables visible the instant it posts the moment you're running two systems instead of one real time visibility isn't a feature you're missing it's a promise that was only ever true for a version of your business that doesn't exist anymore eventually somebody stops accepting the lag as a cost of doing business and starts running the actual math not a gut feeling about whether the patchwork is annoying a real comparison what is holding this together keep costing month after month against what it would cost to just migrate and be done with the seams entirely the break even point when patchwork costs more than migration this isn't a decision that gets made in a meeting it gets made on a spreadsheet quietly usually by someone in finance who finally sat down and added up what the patchwork actually costs every month instead of just feeling the pain of it during close list out what the patchwork actually charges you integration maintenance the ongoing work of keeping the sync jobs running and fixing them when they break custom elimination logic built once but never finished because every new acquisition adds another mapping another edge case another reconciliation rule someone has to write and test i.t headcount babysitting sync jobs that were supposed to run themselves delayed closes month after month that push finance further behind schedule every quarter ordered friction because every auditor who touches this environment has to trace a transaction across three separate logs before they can sign off on anything none of these show up as one line item they hide in different budgets different departments different headcount requests that never get compared against each other directly now put migration on the other side of that ledger a phased business central to finance and operations project runs 12 to 18 months that's real money real disruption a real line item that makes a CFO wins the first time they see the number but here's what actually happens when organizations run this comparison honestly side by side instead of comparing a monthly patchwork cost against a headline migration number that looks scary in isolation migrating consolidation entirely into finance and operations frequently ends up cheaper than maintaining a fragile multi-system integration indefinitely not because migration is cheap because indefinitely is a long time and every month the patchwork survives it adds another month of maintenance cost another acquisitions worth of new mapping work another quarter of a close that runs longer than it should here's the part nobody wants to say out loud and it's worth naming directly because it's the real reason companies wait past the point where the math already flipped sunk cost leadership spent years building that integration they spent real money getting the sync jobs configured getting the elimination logic custom built training a team to babysit all of it admitting that the whole thing needs to be replaced feels like admitting the years and the money were wasted like standing up in front of the board and saying the plan everyone signed off on was wrong it wasn't wrong that's worth saying plainly because it isn't failure it's a system reaching the edge of what it was ever built to carry business central wasn't designed to hold five acquisitions together forever nobody failed by building a patchwork that worked for three years the patchwork did its job it bought time eventually time runs out and the math on the spreadsheet says so before anyone in the room is ready to hear it if migration becomes the answer once that math lands the next question is what that migration actually asks of the organization because migration is about to turn out to be the wrong word for what's coming why migration is the wrong word say it plainly moving from business central to finance and operations is not a migration in the way naev to bc was a migration that word carries baggage it hasn't earned here and the baggage is exactly what sets budgets and timelines wrong from day one look at what naev to bc actually was because it's the closest comparison most it leaders have in their heads same lineage same underlying logic running under the hood customizations got rebuilt as extensions instead of full ground up rebuilds and data carried forward with the conversion process that while not trivial worked within a shared set of assumptions about how a ledger entry behaves and how a dimension gets tagged naev to bc stayed inside one family different furniture same house bc to fn o crosses align naev to bc never came close to different table structures built by different teams in different decades for different scales of business entirely different posting logic meaning a transaction doesn't just look different it behaves differently once it lands different account frameworks meaning even the concept of what a chart of accounts is capable of expressing changes underneath you this isn't a bigger house with the same furniture it's a different foundation a different frame a different set of load bearing walls so walk through what actually happens once you strip the label migration off and look at the real steps underneath first extraction pulling data out of business central in a form that means something once it's no longer sitting inside bc's own internal logic second transformation reshaping that extracted data to fit a schema that was never designed with bc's structure in mind translating concepts that don't have a clean one-to-one equivalent on the other side third loading pushing that transform data into finance and operations using fn o's own data management tools tools build assuming enterprise grade structure walks in the door not small business simplicity fourth validation checking every number every account every balance confirming what landed on the fn o side actually matches what left business central line by line with no short cuts each of those four steps is a project in its own right not a phase inside one tidy migration plan not a checkbox somebody takes off on a Friday afternoon extraction alone can surface data quality problems nobody knew existed transformation alone can take weeks once you hit the accounts that don't map cleanly loading alone requires someone who actually understands fn o's data management framework well enough not to break something on the way in validation alone means somebody sits with two sets of numbers and refuses to sign off until they match which sometimes takes longer than anyone budgeted for calling this a migration under cells it's so badly that the damage starts before the project even kicks off it sets a budget sized for moving furniture when what's actually required is pouring a new foundation it sets a timeline sized for software upgrade when what's actually required is four separate projects stacked on top of each other each with its own way of going wrong the word itself is where the mistake begins business process redesign not data transfer everything up to this point has been about data extraction transformation loading validation necessary work expensive work but not the hardest work the hardest work is process and almost nobody budgets for it the way they should business central approval workflows its posting groups its dimensions none of that maps cleanly onto how finance and operations expects a business to run these aren't cosmetic differences you patch with a settings change they're different philosophies about how work should move through an organization and every team that touches the ERP has to unlearn one philosophy and pick up the other take procurement because it shows the gap clearly in business central a purchase starts on a requisition worksheet someone flags a need roots it through an approval chain and a purchase order comes out the other side simple direct built for a company where procurement doesn't need much ceremony finance and operations runs a completely different model full requisition management with punch out capability that connects directly into supplier catalogs multi-stage approval routing that can vary by category or spend threshold demand planning tied into the request before it even becomes a formal purchase that's not the same process running on a different screen it's a different answer to the question of what procurement is supposed to accomplish built for organizations where a thousand requisitions a month is normal and a single mis-approval step can mean a compliance problem manufacturing splits the same way business central handles discrete manufacturing full stop build a defined product from a bill of materials run it through a production order done finance and operations handles discrete manufacturing and process manufacturing both because enterprise operations often need to track a batch of chemicals or a continuous production run alongside a discrete assembly line sometimes in the same facility a manufacturing team that's only ever configured discrete workflows in BC is walking into a system that assumes it might need to handle both and figuring out which parts of that apply takes real time not a quick orientation session this is the part that gets missed in almost every planning conversation it isn't just finance that has to relearn its process it's every team that touches the ERP procurement has to relearn what a requisition actually is inside the system manufacturing has to relearn how a production order gets structured sales has to relearn how pricing and order management behave under F&O's more elaborate rules nobody gets to keep doing their job the exact same way with new buttons and new places they're learning a different set of assumptions about how their own work is supposed to flow that's the real reason F&O implementations run six to 18 months and it's worth saying directly because most people assume the length comes from slower software rollout more servers to configure more testing cycles to run it isn't that it's organizational relearning spread across every department that depends on the system to do its job you can extract and transform data in a few focused sprints you cannot compress the time it takes an entire procurement team to internalize a different approval philosophy or a manufacturing team to reconfigure how it thinks about a production order none of this holds together though if what's underneath it is a mess a redesigned process running on top of duplicate vendor records and unreconsiled balances doesn't fix anything it just gives the mess a new interface to hide behind the data cleanup nobody budgets for most disruption at go live doesn't come from the problems everyone sees coming it comes from the small undocumented ones nobody thought to mention because nobody remembered they existed until something broke duplicate vendor records that got created twice years apart by two different people who didn't know the other one had already set it up unreconsiled balances sitting quietly on a sub ledger never causing a visible problem because nobody was looking closely enough to notice customizations somebody built five years ago solved a real problem at the time and then got forgotten the moment the person who built it left the company none of these show up on a project plan all of them show up the week after go live usually during the first close usually at the worst possible time here's the thing worth correcting directly because it's the opposite of what most people worry about going in the risk was never bringing too little data across nobody's implementation fails because they forgot to migrate something small the risk is bringing dirty data across cleanly formatted perfectly extracted transformed and loaded exactly as instructed and still wrong because the mess was already baked into the source system before anyone touched it so the discipline that actually protects the migration starts before extraction even begins retain a defined window of historical data typically no more than seven years and archive the rest somewhere it stays accessible for audit purposes without cluttering the new system that's not a data limitation it's a decision made on purpose about what actually needs to live inside the live environment versus what just needs to exist somewhere retrievable the harder discipline is customizations and this is where most teams underestimate the work by an order of magnitude every custom field every workflow tweak built into the old business central environment needs to go through the same classification exercise one by one with no exceptions made for the ones that feel too small to bother with rebuild it as something equivalent inside FNO replace it with a native feature that already does the job better than the custom version ever did find an equivalent app that solves the same problem without custom code or retire it entirely because half the time nobody using the system today actually needs what it was built to do that classification work sounds administrative it isn't it's the difference between a go live that surfaces a handful of known gaps the team already planned around and a go live that surfaces a dozen surprises nobody had time to prepare for because nobody wrote them down when they still could have the migrations that fail aren't failing on the big visible stuff extraction gets planned transformation gets planned loading gets planned what syncs a project is the stuff nobody wrote down sitting quietly in a corner of the old system waiting for someone to trip over it during the one week everyone least wants surprises what gets left behind not everything comes over and that's by design not failure a clean migration doesn't mean carrying every piece of the old system forward and setting it down gently inside the new one it means deciding on purpose what actually deserves a seat at the table in FNO and what stays behind because it never needed to make the trip old custom code is the clearest case something written years ago to solve a problem specific to business central structure built around BC's tables BC's event model BC's way of extending a process often has no equivalent in FNO's architecture at all not a worse version not a simplified version no version because the problem it solved either doesn't exist inside FNO design or gets handled by a completely different mechanism nobody thought to compare it against trying to force that old code into the new environment doesn't preserve anything it just recreates a work around for a problem the new system was never going to have in the first place reports carry the same trap and it's a common one because reports feel like they should just move they don't a report built against business central data model isn't something you re-point at a new data source and call finished the underlying schema is different the tables don't line up the fields that used to sit next to each other don't live in the same place anymore every report that matters has to get rebuilt against FNO's schema from the ground up not patched not redirected anyone who budgets for reporting as a quick fix during migration finds that out the hard way usually right when finance asks for the first month and report and nobody can produce it historical data gets its own answer to separate from what's been said about retention windows some of it simply stays where it is the old business central environment gets kept in read only mode accessible for audit purposes for 12 to 24 months at minimum so anyone who needs to trace something back to a transaction from before cut over still can without cluttering the live FNO environment with data nobody's actively working against anymore here's the reframe worth holding on to a migration that drags every piece of old baggage forward every dead customization every report nobody rebuilt properly every scrap of history that could have stayed archived isn't a clean start it's just moving the same mess into a more expensive system and paying enterprise grade licensing to keep storing it which raises a fair question one that's been sitting underneath this entire conversation if the wall is this real this structural this expensive to cross why does anyone build on business central in the first place knowing growth might run them straight into it the case for starting on bc anyway fair question and it deserves a straight answer instead of a hedge does all of this mean business central was a bad choice from the start some kind of trap dressed up as an entry point no and the reason matters more than the denial itself bc speed and cost make it the right start for the size a company actually is today not the size it might become in a scenario that hasn't happened yet and might never happen at all three to six months to implement against six to eighteen eighty dollars a user against two hundred that gap isn't a rounding error when cash is tight when a finance team is small enough that one person wears three hats that difference in cost and speed is the difference between getting a working system live this year or spending 18 months in a budget the company doesn't have chasing enterprise features nobody on staff would even use yet here's what gets missed in most of these conversations and it's worth saying plainly most companies that start on business central never hit the F&O wall not because they got lucky because most companies simply don't do the kind of multi entity multi country growth that triggers the collision in the first place they grow they add customers add revenue add head count they don't add a second legal entity in another country or acquire a competitor running a different ERP or find themselves suddenly answerable to a board that once one consolidated number across five subsidiaries growth in scale and growth in shape are two different things and only one of them runs you into this particular wall so the mistake was never choosing business central the mistake is assuming business central was designed to carry a company past that specific growth pattern without any plan for what happens if it shows up nobody picks bc and gets punished for picking bc companies get hurt when they pick bc grow in exactly the shape that breaks it and never once stop to ask what happens if that shape of growth actually arrives here's the point worth landing before moving forward business central is the right tool for a real common size and shape of business the kind that makes up the overwhelming majority of companies that will ever touch this ecosystem the trap doesn't spring because a company grew it springs when growth changes the shape of the business not just the size of it multiple entities multiple countries consolidation demands nobody architected for and the company walks into that shift without having asked the question early enough to matter that's the real dividing line dot bc versus F&O growth you plan for versus growth you didn't designing for the size you'll become so the question shifts not did we pick the right system but what do we do differently starting now if we're the kind of company that might grow into this shape someday start with the chart of accounts because this is the cheapest place to plan and the most expensive place to fix later build it and the dimension structure underneath it with consolidation in mind even when you're running one entity and consolidation isn't a problem yet that doesn't mean over complicating a simple business that means choosing account structures and dimension values that wouldn't need to be torn apart if a second entity showed up next year a little discipline here costs almost nothing today untangling a chart of accounts that grew organically with no plan three acquisitions deep costs real money and real time next figure out early which pieces of data will eventually need to cross a system boundary because some data always does the moment a company grows in shape rather than just size customer master vendor master product master the GL structure itself these are the records that end up living in two places at once the day an acquisition happens and deciding now how they're structured named and coded is a lot cheaper than reverse engineering consistency across five years of inconsistent entry after the fact that's where data verse belongs in this conversation not as something you bolt on in a panic after acquisition number two but as a possible shared layer you at least architect award from the start you don't need to build the full integration today you do need to avoid building master data in a way that makes a shared layer impossible later as we saw earlier BC and FNO each connect to data verse through their own separate mechanisms planning for that reality now instead of discovering admit crisis is the difference between an integration project and an integration emergency and then there's the discipline almost nobody keeps the one that costs nothing but attention document every customization the day it gets built not five years later when someone new joins the team and asks what a field does and nobody left can answer not during a migration when a classification exercise turns into archaeology the day it's built while the person who built it still remembers why none of this means overbuilding for a future that might not arrive most companies on business central will never need any of this the point isn't to architect like an acquisition is coming it's to leave the door unlocked instead of welding it shut so that if growth does change shape instead of just size the company isn't starting from zero that's the theory it stays theory until a company actually goes through it until the acquisition lands on a Monday morning and someone has to make these decisions under a deadline instead of in a planning session with time to think a realistic M&A scenario walkthrough here's how this actually plays out start to finish in a scenario built from the pattern that keeps repeating across companies that hit this wall a mid-size company runs business central solid operation clean books one entity one country it acquires a competitor similar size also running business central but in a different country entirely different tax rules different currency different chart of accounts built by a different consultant years ago with no coordination between the two the intention coming out of the deal is simple to state and hard to deliver close the acquisition then report combined numbers to the board within one quarter leadership wants to show the market this deal is already paying off one number combined revenue combine margin one story instead of two the obstacle shows up almost immediately two separate business central databases running independently with no shared connection between them two charts of accounts that don't map on to each other cleanly because nobody built them with the other one in mind and underneath both of those something worse two different definitions of what actually counts is revenue recognition one entity recognizes revenue on shipment the other recognizes it on invoice nobody notices this mismatch until someone tries to add the two together and the combined number doesn't reconcile against either underlying system there's no time to architect anything proper before that first board update is due so the stopgap is the one every company reaches for under deadline pressure manual consolidation in spreadsheets someone on the finance team pulls exports from both BC instances maps the accounts by hand adjust for the revenue recognition gap manually and builds a combined view good enough to present it works barely and it buys time nobody realizes is actually being spent six months in the spreadsheet process starts breaking down in the way these things always do quietly at first transaction volume grows past what a manual process can absorb without cracks showing the manual mapping that worked fine at low volume starts missing things at higher volume errors creep into board reporting small at first a mismatched account here a rounding issue there then large enough that someone on the board asks a question finance can't answer cleanly in the meeting this is the exact moment the finance and operations conversation starts getting set out loud not as a theoretical someday but as an actual line item on someone's task list and it's the exact moment the there's no direct path reality lands with full weight because up until this point most of the people in the room assumed a bridge existed somewhere now they're finding out otherwise mid crisis with a board already asking uncomfortable questions the resolution that actually works isn't a switch flip it's a face plan business central stays live in both subsidiaries during the transition because ripping it out immediately would break operations nobody has time to rebuild under pressure finance and operations comes in first as the consolidation and reporting layer sitting above both BC instances giving the board one number without requiring either subsidiary to change how it works day to day full migration into FNO follows later over 12 to 18 months once the business has stabilized enough to absorb a project of that size without breaking something else in the process the faced path that actually works lay that scenario next to the fantasy version most people picture when they first hear we're moving to FNO and the gap is obvious nobody flips a switch on a Friday and wakes up Monday with one clean system what actually works is slower less dramatic and comes in four phases that each have to finish before the next one starts making sense phase one stabilize each business central instance on its own before anyone touches integration clean the data inside each subsidiary document every customization sitting in each environment the same classification discipline covered earlier applied separately to each BC instance rather than assume to be consistent across them this step gets skipped constantly because it feels like standing still while the real work waits it isn't standing still two clean systems are easier to connect than two messy ones and building integration on top of unresolved data problems just moves the mess one layer up phase two build the data verse and integration layer for shared master data as we covered earlier BC and FNO each connect to data verse through their own separate mechanisms and the sink cadence runs on a schedule not in real time go into this phase already knowing that not discovering it three months in when finance asks why headquarters numbers look stale build the integration around that reality instead of hoping it turns out faster than documented phase three decide the elimination and consolidation logic on purpose don't assume fnose native module will absorb intercompany transactions coming from an outside BC system because it won't reach across that boundary automatically this has to be built tested and owned by someone specific not inherited as a side effect of turning fn o on phase four run the actual BC to fnome migration as its own project its own budget its own timeline its own testing window separate from the integration work in phase two and the consolidation logic in phase three bundling this into the integration project is how timelines quietly triple one more piece belongs inside phase four and it's the one organization's cut first when a deadline gets tight a parallel run period two to four weeks minimum both systems live at once producing numbers side by side not a demo a real operating window where finance checks that fnose output matches what BC would have produced transaction by transaction before anyone commits to a full cutover skip this and the discrepancies don't disappear they just wait until after cut over when they're harder to trace and more expensive to fix here's what ties all four phases together every phase that gets skipped early doesn't vanish from the project it shows up later dressed up as a fire nobody budgeted for costing more to put out than it would have cost to handle properly the first time the order isn't a suggestion it's the only sequence where each phase actually protects the one that comes after it common mistakes that make this worse five mistakes show up again and again in these projects and none of them are exotic they're the ordinary kind the kind that feel reasonable in the moment and only look like mistakes once the invoice for them arrives mistake one waiting until the acquisition closes to think about integration the deal team runs due diligence on financials on legal exposure on customer contracts and nobody in that room asks what ERP the target runs or what it would take to connect it integration planning starts the week after signing instead of the month before which means the company loses exactly the window when it had the most leverage to shape the deal terms around what the systems could actually support mistake two assuming it can quietly handle this in the background no budget line no headcount allocated just an expectation that the existing team will absorb a multi-system integration on top of everything else they're already doing i doesn't say no because it rarely gets asked in a way that invites a no the work gets done badly slowly or both and nobody upstream understands why until the numbers start looking wrong mistake three treating the finance and operations move as a technical project instead of a business process redesign as covered earlier the hard part isn't the data it's the process and a project plan that only staffs developers and database people misses the actual work entirely procurement manufacturing sales all of them need seats at that table from the start not a training session bolted on at the end mistake four keeping every scrap of historical data instead of defining a retention window upfront this one feels safe in the moment like nobody ever got in trouble for keeping too much but undefined retention means undefined scope an undefined scope is how a project that should take 12 months quietly becomes 18 one unreviewed data set at a time mistake five skipping the parallel run period to save time the deadlines tight the boards asking questions and running two systems side by side for a month feels like a delay nobody can afford so it gets cut and the discrepancies that period would have caught don't disappear they just wait until after cut over when tracing them back to a root cause takes three times as long and costs three times as much look at these five side by side and one thing stands out they don't share a technical cause they share a psychological one every single mistake comes from treating this wall as a surprise something nobody could have seen coming instead of what it actually is a known feature of how these two systems relate to each other the organizations that avoid these mistakes aren't smarter they just stopped being surprised what this means for the next five years zoom out from any single company story and the patent sits underneath all of it this isn't going away if anything it's getting more common because more companies are growing through acquisition then through slow organic expansion and every acquisition carries a chance of landing two ERPs in the same org chart private equity roll-up activity is the clearest driver here the playbook is well known at this point by a handful of small companies in the same industry combine them sell the combined entity at a multiple higher than any single piece would have fetched alone each of those small companies almost certainly already runs an ERP and a meaningful share of them run business central because BC is exactly the kind of system a company that size chooses that means the collision covered throughout this episode isn't a rare edge case some unlucky IT director stumbles into it's a structural feature of how a large and growing share of the activity actually works Microsoft's roadmap doesn't close this gap either and it's worth being precise about why the investment keeps flowing into data verse into co-pilot into connective tissue that makes moving data between products smoother than it used to be that investment is real and it helps but connective tissue isn't the same thing as a bridge between two different architectures a better sync job doesn't change the fact that business central and finance and operations were built on different assumptions about scale different posting logic different data models Microsoft is making the seems less painful to manage Microsoft isn't erasing the scene so the organizations that come out ahead of this pattern aren't the ones avoiding business central waiting for some future version of the ecosystem where the wall doesn't exist that version isn't coming the ones who come out ahead are the ones who architect for consolidation before they needed who treat the chart of accounts the master data the documentation habits covered earlier as groundwork laid on a normal Tuesday not as a crisis response after the deal already closed the wall isn't disappearing that's the plain fact underneath everything in this episode the only variable left for any given company is whether they see it coming from a distance with time to plan a phased approach or whether they hit it at full speed in the middle of a deal with a board already asking questions nobody has good answers to yet key transformation and implementation challenge here's the shift this whole episode has been building toward stated as plainly as it can be stated moving from business central to finance and operations isn't an upgrade it's a decision to rebuild on a different foundation and the earlier that decision gets made on purpose the cheaper every part of it gets that's not an abstract principle it turns into a specific task one you can start this quarter instead of filing away as some day work if you're running business central today and any acquisition is even a possibility over the next two years even a vague one even one that's just a rumor in the industry you're in audit your chart of accounts and your customizations now before the deal happens not after the term sheet is signed and someone in finance is suddenly building spreadsheets under deadline pressure that audit doesn't need to be exhaustive to be useful it needs to exist know what's documented and what isn't know which customization solver real problem and which ones nobody remembers the reason for know whether your chart of accounts could survive a second entity showing up next to it without a rebuild none of that requires predicting the future it just requires refusing to be surprised by it here's the stakes worth naming one final time because it's the whole point of everything covered so far the companies that get hurt in this pattern aren't the ones that stayed on business central staying on BC was never the mistake the companies that get hurt are the ones that assumed a bridge existed between BC and F&O some upgrade path Microsoft would eventually build and found out otherwise in the middle of a deal with a board waiting on numbers and no time left to plan properly that's where we'll leave it for this episode if this saved you from budgeting a migration that was actually a full rebuild in disguise that's worth a review on the m365fm podcast say so directly it helps other people find this before their mid deal and scrambling for answers if you want to keep this conversation going connect with me my co-peters on linkedin and their most days and i genuinely like to hear which Microsoft ecosystem assumption deserves the same kind of structural breakdown next there's no shortage of them one last thing stated planions that have wrapped in false comfort the wall between BC and F&O isn't going anywhere so plan for it before it plans for you