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

1
00:00:00,000 --> 00:00:04,220
six years on Business Central, clean data, solid reporting, finance team that actually trusts

2
00:00:04,220 --> 00:00:05,220
the numbers.

3
00:00:05,220 --> 00:00:08,620
Then the acquisition happens and someone on the leadership team says the line you've probably

4
00:00:08,620 --> 00:00:14,220
heard before will move to finance and operations eventually, eventually never comes.

5
00:00:14,220 --> 00:00:17,700
Not because nobody wants to do it, because there's no path to work.

6
00:00:17,700 --> 00:00:21,420
Most IT leaders picture Business Central and Finance and Operations sitting on the same

7
00:00:21,420 --> 00:00:25,620
ladder, one rung apart, outgrow one, climb to the next, that picture is wrong.

8
00:00:25,620 --> 00:00:29,380
The reason there's no upgrade button isn't a licensing restriction Microsoft could lift

9
00:00:29,380 --> 00:00:30,380
with a policy change.

10
00:00:30,380 --> 00:00:33,940
It's structural, it's buried in the data model itself, in how each system was built

11
00:00:33,940 --> 00:00:34,940
and who it was built for.

12
00:00:34,940 --> 00:00:37,500
By the end of this, you'll know exactly where that wall sits.

13
00:00:37,500 --> 00:00:41,020
You'll know why merges and acquisitions hit it harder than almost anything else, and

14
00:00:41,020 --> 00:00:45,740
you'll know what to build instead of waiting for a bridge that was never designed to exist.

15
00:00:45,740 --> 00:00:47,260
Welcome back to M365FM.

16
00:00:47,260 --> 00:00:50,540
If you haven't hit subscribe yet, do that now because we get into the parts of the Microsoft

17
00:00:50,540 --> 00:00:52,700
ecosystem that don't show up in the sales deck.

18
00:00:52,700 --> 00:00:56,060
Today, we're breaking down the Business Central to finance and operations trap.

19
00:00:56,060 --> 00:00:59,220
It's a trap because it catches growing companies exactly when they can at least

20
00:00:59,220 --> 00:01:03,740
afford a surprise, usually mid acquisition, usually with a board waiting on numbers.

21
00:01:03,740 --> 00:01:07,180
Let's get into why this even becomes a question in the first place.

22
00:01:07,180 --> 00:01:09,180
Why this question even comes up?

23
00:01:09,180 --> 00:01:13,300
Business Central gets sold with a specific promise baked into the pitch.

24
00:01:13,300 --> 00:01:15,700
Start here, grow into anything.

25
00:01:15,700 --> 00:01:19,340
Essentials for the basics, premium ones you need manufacturing or service management, and

26
00:01:19,340 --> 00:01:22,740
finance and operations waiting somewhere down the road once you're ready.

27
00:01:22,740 --> 00:01:26,980
It reads like a ladder, step one, step two, step three, and the top step is enterprise

28
00:01:26,980 --> 00:01:27,980
scale.

29
00:01:27,980 --> 00:01:30,340
Streaming isn't malicious, but it's misleading.

30
00:01:30,340 --> 00:01:31,340
And here's why.

31
00:01:31,340 --> 00:01:35,100
Business Central and finance and operations were never the same product stretched across

32
00:01:35,100 --> 00:01:36,100
company sizes.

33
00:01:36,100 --> 00:01:39,540
They're two separate systems with two separate lineages, and that distinction matters more

34
00:01:39,540 --> 00:01:41,580
than almost anything else in this conversation.

35
00:01:41,580 --> 00:01:43,700
Business Central comes from Dynamics Nav.

36
00:01:43,700 --> 00:01:46,420
Finance and operations comes from Dynamics AX.

37
00:01:46,420 --> 00:01:50,140
Different code bases built in different countries designed in different decades for different

38
00:01:50,140 --> 00:01:51,140
problems.

39
00:01:51,140 --> 00:01:54,060
Nav was built for speed and simplicity in smaller operations.

40
00:01:54,060 --> 00:01:58,620
AX was built from the start for organizations with global footprints and financial complexity

41
00:01:58,620 --> 00:02:00,540
that Nav was never asked to handle.

42
00:02:00,540 --> 00:02:05,100
Microsoft didn't take one product and split it into a small version and a big version.

43
00:02:05,100 --> 00:02:09,180
It kept two products with different DNA and marketed them under one umbrella.

44
00:02:09,180 --> 00:02:11,060
So here's what actually happens on the ground.

45
00:02:11,060 --> 00:02:14,580
The company runs Business Central for years, everything works, and then someone in a strategy

46
00:02:14,580 --> 00:02:18,740
meeting starts talking about acquisitions or a second country or consolidating financials

47
00:02:18,740 --> 00:02:20,380
across multiple entities.

48
00:02:20,380 --> 00:02:22,140
And almost on cue somebody says it.

49
00:02:22,140 --> 00:02:24,460
It'll just upgrade to F&O later.

50
00:02:24,460 --> 00:02:25,540
That sentence is the trap.

51
00:02:25,540 --> 00:02:26,540
It sounds like a plan.

52
00:02:26,540 --> 00:02:30,260
It sounds like the kind of thing you write into a three year road map slide and move on,

53
00:02:30,260 --> 00:02:33,620
but it assumes a bridge exists between these two systems that simply isn't there.

54
00:02:33,620 --> 00:02:38,020
It assumes upgrade means what it meant when nave moved to business central.

55
00:02:38,020 --> 00:02:42,820
Same lineage, same logic, data carrying forward with some conversion work.

56
00:02:42,820 --> 00:02:46,660
Business Central to finance and operations doesn't work that way, and understanding exactly

57
00:02:46,660 --> 00:02:49,380
why is where we're headed next.

58
00:02:49,380 --> 00:02:50,900
The assumption that breaks.

59
00:02:50,900 --> 00:02:54,380
Here's the model most people carry around in their head without ever questioning it.

60
00:02:54,380 --> 00:02:55,620
ERP is a single track.

61
00:02:55,620 --> 00:02:59,060
You start small, you outgrow the system, you step up to the bigger one.

62
00:02:59,060 --> 00:03:04,180
It's the same logic as moving from a starter apartment to a house, more space, same neighborhood,

63
00:03:04,180 --> 00:03:05,820
same city, just bigger rooms.

64
00:03:05,820 --> 00:03:07,820
That model works fine for some transitions.

65
00:03:07,820 --> 00:03:11,500
It does not work here, and the reason it doesn't work is worth naming directly instead

66
00:03:11,500 --> 00:03:12,780
of hinting at.

67
00:03:12,780 --> 00:03:16,860
People assume upgrade means moving data forward the same way it moved when nave became Business

68
00:03:16,860 --> 00:03:19,900
Central, same tables mostly, same posting logic mostly.

69
00:03:19,900 --> 00:03:24,020
A conversion tool does the heavy lifting, extensions replace old customizations, and six months

70
00:03:24,020 --> 00:03:27,780
later you're running a newer version of the same underlying system with a better interface

71
00:03:27,780 --> 00:03:28,780
and cloud hosting.

72
00:03:28,780 --> 00:03:31,260
That's what an upgrade looks like when it's real.

73
00:03:31,260 --> 00:03:33,500
Business central to finance and operations isn't that.

74
00:03:33,500 --> 00:03:37,020
It's not a newer version of the same thing, it's a full re-implementation, and those two

75
00:03:37,020 --> 00:03:40,620
words carry very different weight once you understand what's actually different underneath.

76
00:03:40,620 --> 00:03:42,540
The technical architecture is different.

77
00:03:42,540 --> 00:03:45,780
The data model is different, the posting logic is different, these aren't surface level

78
00:03:45,780 --> 00:03:48,100
differences you patch with a mapping document.

79
00:03:48,100 --> 00:03:52,580
A general ledger entry in Business Central doesn't sit in the same table structure as a general

80
00:03:52,580 --> 00:03:55,340
ledger entry in finance and operations.

81
00:03:55,340 --> 00:03:56,820
Dimensions work differently.

82
00:03:56,820 --> 00:03:59,100
Posting groups don't translate one to one.

83
00:03:59,100 --> 00:04:03,420
Even something as basic as how a transaction gets tagged to a legal entity follows different

84
00:04:03,420 --> 00:04:07,220
rules in each system because each system was built around a different assumption of how

85
00:04:07,220 --> 00:04:10,660
many legal entities exist and how they relate to each other.

86
00:04:10,660 --> 00:04:13,980
So what does re-implementation actually mean once you strip the label off?

87
00:04:13,980 --> 00:04:15,220
It means extraction.

88
00:04:15,220 --> 00:04:18,820
Using data out of Business Central in a format that means something outside of Business Central's

89
00:04:18,820 --> 00:04:20,260
own internal logic.

90
00:04:20,260 --> 00:04:24,820
It means transformation, reshaping that data to fit a completely different schema.

91
00:04:24,820 --> 00:04:27,060
One built for a different scale of complexity.

92
00:04:27,060 --> 00:04:28,540
It means loading.

93
00:04:28,540 --> 00:04:32,780
Pushing that transformed data into finance and operations using its own data management

94
00:04:32,780 --> 00:04:33,780
tools.

95
00:04:33,780 --> 00:04:38,420
Tools that assume you're bringing in enterprise grade structure, not small business simplicity.

96
00:04:38,420 --> 00:04:39,740
And it means validation.

97
00:04:39,740 --> 00:04:43,580
Checking, line by line, account by account, that what landed on the other side actually

98
00:04:43,580 --> 00:04:45,820
matches what left the original system.

99
00:04:45,820 --> 00:04:49,220
Each of those four steps is a project, not a checkbox on a project plan, not a week

100
00:04:49,220 --> 00:04:53,140
and task for an integration specialist, a project with its own risks, its own timeline,

101
00:04:53,140 --> 00:04:55,060
its own places where things go wrong.

102
00:04:55,060 --> 00:04:56,660
Here's where the real damage happens.

103
00:04:56,660 --> 00:04:59,300
And it's not technical, it's financial.

104
00:04:59,300 --> 00:05:02,580
Companies sit down, look at what NAFTA BC Migrations cost, look at what BC to BC version

105
00:05:02,580 --> 00:05:05,220
upgrades cost, and they budget for something in that range.

106
00:05:05,220 --> 00:05:06,380
A migration.

107
00:05:06,380 --> 00:05:11,300
A few months, a defined scope, a partner quote that feels proportional to moving to a new

108
00:05:11,300 --> 00:05:12,300
system.

109
00:05:12,300 --> 00:05:15,740
Then the actual project starts and it behaves like what it actually is.

110
00:05:15,740 --> 00:05:19,620
A full implementation, at implementation cost on an implementation timeline.

111
00:05:19,620 --> 00:05:24,060
The budget that felt reasonable in the boardroom is suddenly short by a wide margin and the

112
00:05:24,060 --> 00:05:28,780
timeline that got promised to the board is suddenly off by months, sometimes longer.

113
00:05:28,780 --> 00:05:32,260
To understand why no bridge exists to soften any of this, you have to look at what these two

114
00:05:32,260 --> 00:05:36,620
systems were actually built to do in the first place and who they were built to serve.

115
00:05:36,620 --> 00:05:38,660
What business central was actually built for?

116
00:05:38,660 --> 00:05:43,420
What was built with who business central was designed for?

117
00:05:43,420 --> 00:05:46,460
Because that answers almost every question about why it behaves the way it does.

118
00:05:46,460 --> 00:05:48,980
One entity or a small handful of connected ones.

119
00:05:48,980 --> 00:05:49,980
One country or a few.

120
00:05:49,980 --> 00:05:53,860
One finance team that knows every account by heart because there aren't thousands of

121
00:05:53,860 --> 00:05:54,860
them to memorize.

122
00:05:54,860 --> 00:05:55,860
That target shapes everything.

123
00:05:55,860 --> 00:05:59,060
Implementation runs three to six months because the software doesn't ask you to make a

124
00:05:59,060 --> 00:06:02,820
thousand configuration decisions before you can post a single invoice.

125
00:06:02,820 --> 00:06:06,060
The cost per user stays low because the system isn't carrying the weight of features,

126
00:06:06,060 --> 00:06:08,060
a small business will never touch.

127
00:06:08,060 --> 00:06:10,860
One of the central ships with an assumption baked in.

128
00:06:10,860 --> 00:06:14,580
Most companies using this don't want to configure a general ledger from scratch.

129
00:06:14,580 --> 00:06:18,020
They want one that already works and lets them tweak the edges.

130
00:06:18,020 --> 00:06:20,780
That's the core design philosophy stated plainly.

131
00:06:20,780 --> 00:06:22,460
Simplicity is the default state.

132
00:06:22,460 --> 00:06:25,780
Complexity is the exception you bolt on when you actually need it.

133
00:06:25,780 --> 00:06:28,180
Not the baseline you wade through just to get started.

134
00:06:28,180 --> 00:06:31,740
Look at who's actually sitting in front of this software all day.

135
00:06:31,740 --> 00:06:34,860
Finance teams closing the books for one company, maybe two.

136
00:06:34,860 --> 00:06:38,940
These managers tracking inventory across a single warehouse or a small regional network.

137
00:06:38,940 --> 00:06:43,020
Procurement staff running purchase orders through a straightforward approval chain.

138
00:06:43,020 --> 00:06:46,620
Small manufacturing shops assembling discrete products on a production floor they can walk

139
00:06:46,620 --> 00:06:48,100
across in five minutes.

140
00:06:48,100 --> 00:06:52,020
None of these users are managing global tax jurisdictions or reconciling six currencies

141
00:06:52,020 --> 00:06:53,700
against the central treasury function.

142
00:06:53,700 --> 00:06:57,420
They're running a business and the software gets out of the way so they can do that.

143
00:06:57,420 --> 00:07:00,900
Now look under the hood because this is where the design philosophy becomes structural

144
00:07:00,900 --> 00:07:02,380
rather than just a feeling.

145
00:07:02,380 --> 00:07:06,140
The tables in business central that dimensions the posting groups all of it gets built around

146
00:07:06,140 --> 00:07:10,500
the idea of one company or a small set of companies that talk to each other in fairly simple

147
00:07:10,500 --> 00:07:11,500
ways.

148
00:07:11,500 --> 00:07:15,020
A dimension in business central tracks something like department or region sure but it's not

149
00:07:15,020 --> 00:07:19,460
architected to carry the weight of multi entity elimination logic across a dozen legal structures

150
00:07:19,460 --> 00:07:20,740
in a dozen countries.

151
00:07:20,740 --> 00:07:21,740
It was never asked to.

152
00:07:21,740 --> 00:07:24,660
This is the point worth sitting with before moving on.

153
00:07:24,660 --> 00:07:27,500
Business central isn't a smaller version of finance and operations with some menu items

154
00:07:27,500 --> 00:07:28,500
grade out.

155
00:07:28,500 --> 00:07:31,820
It's not F&O with the enterprise features hidden behind a paywall.

156
00:07:31,820 --> 00:07:38,140
It's a separate design philosophy from the ground up built around a different question entirely.

157
00:07:38,140 --> 00:07:43,060
F&O's architects asked how do we handle enterprise complexity at scale business central's architects

158
00:07:43,060 --> 00:07:44,380
asked.

159
00:07:44,380 --> 00:07:48,060
How do we get a growing company running in weeks instead of months without making them think

160
00:07:48,060 --> 00:07:52,340
about problems they don't have yet two different questions produce two different systems.

161
00:07:52,340 --> 00:07:56,460
And once you see it that way the next question answers itself what happens when you ask the

162
00:07:56,460 --> 00:08:00,220
same architecture to solve the other question instead.

163
00:08:00,220 --> 00:08:02,860
What finance and operations was actually built for?

164
00:08:02,860 --> 00:08:06,900
Flip the question around and you get finance and operations where business central starts

165
00:08:06,900 --> 00:08:13,060
from one entity and a small footprint F&O starts from the opposite assumption entirely.

166
00:08:13,060 --> 00:08:18,820
Large enterprise multiple legal entities multiple countries and consolidation that has to happen

167
00:08:18,820 --> 00:08:24,980
automatically not manually because doing it by hand at that scale simply isn't possible.

168
00:08:24,980 --> 00:08:29,060
That starting assumption shows up in the numbers before you even open the software implementation

169
00:08:29,060 --> 00:08:33,620
runs six to 18 months not because the vendors are slower or the consultants less capable

170
00:08:33,620 --> 00:08:38,300
but because the system asks you to make enterprise level decisions before you can post your first

171
00:08:38,300 --> 00:08:39,300
transaction.

172
00:08:39,300 --> 00:08:43,020
Cost per user runs higher for the same reason and the defaults aren't opinionated the way

173
00:08:43,020 --> 00:08:44,540
business central's are.

174
00:08:44,540 --> 00:08:48,980
F&O gives you deep configurability instead because a system built for a thousand different enterprise

175
00:08:48,980 --> 00:08:52,460
shapes can't afford to guess what any one of them needs out of the box.

176
00:08:52,460 --> 00:08:54,940
Here's the mindset shift that matters most.

177
00:08:54,940 --> 00:08:58,500
Business central treats complexity as the exception you add when you need it.

178
00:08:58,500 --> 00:09:03,100
F&O treats complexity as the default state you're managing from day one multiple currencies

179
00:09:03,100 --> 00:09:07,300
aren't a feature you turn on they're assumed automated eliminations aren't a nice to have

180
00:09:07,300 --> 00:09:11,980
they're built into how the system expects consolidated entities to behave advanced manufacturing

181
00:09:11,980 --> 00:09:16,260
scenarios global tax jurisdictions with their own filing requirements layered approval chains

182
00:09:16,260 --> 00:09:19,900
across regions none of that is bolted on afterward it's baked into the architecture from

183
00:09:19,900 --> 00:09:23,500
the first table design decision one number tells you everything about who the system was

184
00:09:23,500 --> 00:09:27,500
built for and it's worth sitting with for a second finance and operations has a minimum

185
00:09:27,500 --> 00:09:32,420
of 20 users business central has a minimum of one that gap isn't a licensing quirk somebody

186
00:09:32,420 --> 00:09:37,660
said arbitrarily it's a signal about scale nobody builds a 20 user floor into a system meant

187
00:09:37,660 --> 00:09:41,900
for a five person finance team you build that floor when you're designing for organizations

188
00:09:41,900 --> 00:09:46,180
where 20 users is already the smaller end of the range consolidation is where this becomes

189
00:09:46,180 --> 00:09:50,580
concrete rather than abstract in F&O consolidation isn't something you configure with a work

190
00:09:50,580 --> 00:09:55,300
around or a third party add on its native the system expects multiple entities to exist

191
00:09:55,300 --> 00:09:59,500
expects them to transact with each other and expects finance teams to need a single consolidated

192
00:09:59,500 --> 00:10:03,740
view without manually reconciling five sets of books by hand every month and that's not

193
00:10:03,740 --> 00:10:07,700
a premium feature sitting behind an upsell it's part of what F&O assumes you need the

194
00:10:07,700 --> 00:10:12,060
moment you open it because the organizations it was designed for never operated any other

195
00:10:12,060 --> 00:10:16,380
way so here's the point worth carrying forward finance and operations isn't business central

196
00:10:16,380 --> 00:10:19,980
with more toggles switched on it isn't the same chassis with a bigger engine dropped

197
00:10:19,980 --> 00:10:24,580
in it's a different chassis altogether built from the ground up to carry enterprise weight

198
00:10:24,580 --> 00:10:28,900
the same way F&O's ancestor dynamics ax was built for organizations that never fit inside

199
00:10:28,900 --> 00:10:33,300
navs design in the first place two systems two different questions answered from the ground

200
00:10:33,300 --> 00:10:37,660
up and that difference stays invisible completely invisible right up until growth forces

201
00:10:37,660 --> 00:10:42,140
the question which is exactly where the next part of the story starts the moment growth

202
00:10:42,140 --> 00:10:46,580
exposes the gap most companies never feel this wall directly they run business central

203
00:10:46,580 --> 00:10:50,140
for years everything working the way it's supposed to and the architecture question

204
00:10:50,140 --> 00:10:55,340
sits dormant because nothing ever forces it awake then one event changes that almost always

205
00:10:55,340 --> 00:10:59,420
it's an acquisition here's how it actually plays out a company runs business central happily

206
00:10:59,420 --> 00:11:03,700
closes its books on time finance trusts the numbers then it acquires another company

207
00:11:03,700 --> 00:11:07,780
or gets acquired itself or opens up in a second country to chase gross leadership signed

208
00:11:07,780 --> 00:11:12,580
off on 18 months ago overnight there isn't one business central instance anymore there

209
00:11:12,580 --> 00:11:17,300
are two sometimes three each one running its own version of the truth its own chart of accounts

210
00:11:17,300 --> 00:11:21,660
its own definitions baked into its own database with nobody outside that entity able to see

211
00:11:21,660 --> 00:11:27,060
inside it cleanly leadership once what leadership always wants in this moment one unified view

212
00:11:27,060 --> 00:11:31,700
of the business a single number for revenue a single number for margin something a CFO can

213
00:11:31,700 --> 00:11:36,180
put in front of a board without a footnote explaining why the number depends on which system

214
00:11:36,180 --> 00:11:40,500
you're looking at and that's exactly where the obstacle shows up immediate and structural

215
00:11:40,500 --> 00:11:44,860
business central wasn't built to consolidate across separate instances natively it was built

216
00:11:44,860 --> 00:11:50,180
around the assumption of one entity or a handful of entities living inside one connected environment

217
00:11:50,180 --> 00:11:54,220
to stand alone business central databases each with its own posting logic don't talk to

218
00:11:54,220 --> 00:11:58,420
each other by default there's no button that merges them into a single reporting layer

219
00:11:58,420 --> 00:12:02,380
the consolidation business central offers assumes you're already inside one house it doesn't

220
00:12:02,380 --> 00:12:06,220
assume you're trying to merge to separate houses built on different foundations the stakes

221
00:12:06,220 --> 00:12:10,700
here aren't abstract without real consolidation financial close stops being a matter of days

222
00:12:10,700 --> 00:12:14,340
and turns into a matter of weeks someone on the finance team is pulling numbers out of

223
00:12:14,340 --> 00:12:18,700
one system someone else is pulling numbers out of the other and both sets land in a spreadsheet

224
00:12:18,700 --> 00:12:24,580
where a human being reconciles them by hand under deadline pressure every single month errors

225
00:12:24,580 --> 00:12:29,380
creep in exactly where you'd expect map to counts the don't line up currency conversions handled

226
00:12:29,380 --> 00:12:33,820
slightly differently in each instance timing differences nobody catches until an auditor asks

227
00:12:33,820 --> 00:12:38,460
about them and once the board starts noticing that the numbers shift between the first draft

228
00:12:38,460 --> 00:12:42,900
and the final version trust erodes fast nobody signs off on a set of financials they've

229
00:12:42,900 --> 00:12:46,820
watched change three times in a week this is usually the exact moment somebody says the

230
00:12:46,820 --> 00:12:50,780
sentence out loud for the first time not in a planning session not on a road map slide months

231
00:12:50,780 --> 00:12:55,700
in advance in a tense meeting after a close that ran two weeks too long someone says let's

232
00:12:55,700 --> 00:12:59,960
just move to finance and operations it sounds like relief it sounds like the obvious next

233
00:12:59,960 --> 00:13:05,060
step after watching to business central instances refused to talk to each other cleanly

234
00:13:05,060 --> 00:13:08,580
what that sentence doesn't account for yet and what the rest of this breaks down is what

235
00:13:08,580 --> 00:13:13,740
actually sits between where that company is standing and where finance and operations lives why

236
00:13:13,740 --> 00:13:18,460
M&A is the real trigger an acquisition explains why the wall shows up it doesn't explain why

237
00:13:18,460 --> 00:13:22,540
the wall gets so much worse so fast for that look at private equity roll ups because they

238
00:13:22,540 --> 00:13:27,660
compress years of organic growth pain into a single deal cycle here's the pattern affirm

239
00:13:27,660 --> 00:13:32,740
buys five small companies inside 18 months folding them into one portfolio company with one

240
00:13:32,740 --> 00:13:37,300
board and one set of investors expecting one clean set of financials each of those five

241
00:13:37,300 --> 00:13:41,780
companies already runs its own ERP before the ink dries on the acquisition several of them

242
00:13:41,780 --> 00:13:45,820
run business central because business central is exactly the kind of system a company that

243
00:13:45,820 --> 00:13:49,940
size would have chosen five years earlier the obstacle doesn't add up in a straight line

244
00:13:49,940 --> 00:13:54,540
it multiplies five separate charts of accounts none of them built with the others in mind five

245
00:13:54,540 --> 00:13:59,220
separate data models each shaped by whichever consultant configured it years ago for a company

246
00:13:59,220 --> 00:14:03,540
that had no idea it would eventually get acquired five different working definitions of something

247
00:14:03,540 --> 00:14:08,660
as basic as customer because one entity tracks billing contacts separately from shipping contacts

248
00:14:08,660 --> 00:14:13,380
and another doesn't bother making that distinction at all none of this is a technical hiccup it's

249
00:14:13,380 --> 00:14:17,700
five independent decisions made independently now expected to collapse into one number on a board

250
00:14:17,700 --> 00:14:23,700
slide inter company elimination is where this stops being theoretical and starts costing real money

251
00:14:23,700 --> 00:14:28,660
as we saw earlier f and o treats consolidation as native what that native module doesn't do is

252
00:14:28,660 --> 00:14:34,180
reach outside its own walls into an external business central system it has no visibility into

253
00:14:34,180 --> 00:14:38,980
f and o's elimination logic was built to handle transactions between entities that already live inside

254
00:14:38,980 --> 00:14:43,780
f and o's architecture a business central subsidiary sitting outside that architecture isn't part of

255
00:14:43,780 --> 00:14:48,820
the conversation the elimination module is designed to have so the moment leadership needs one true

256
00:14:48,820 --> 00:14:54,420
consolidated number custom logic stops being optional and becomes mandatory somebody has to build

257
00:14:54,420 --> 00:14:58,980
the bridge that identifies which transactions in bc correspond to which transactions in f and o

258
00:14:58,980 --> 00:15:03,780
match them flag them and zero them out before anyone reports a combined figure to the board that's

259
00:15:03,780 --> 00:15:08,260
not a checkbox in the settings menu that's a project built and maintained by someone indefinitely

260
00:15:08,260 --> 00:15:12,740
for as long as the patchwork stays in place there's a threshold where this math actually flips

261
00:15:12,740 --> 00:15:17,380
and it's worth naming as a number rather than a feeling once an organization is running more than

262
00:15:17,380 --> 00:15:22,260
three separate business central instances feeding into one consolidation effort or once intercompany

263
00:15:22,260 --> 00:15:27,700
transactions climb past roughly 30% of total bc general ledger volume the cost of holding the patchwork

264
00:15:27,700 --> 00:15:33,140
together starts outpacing the cost of just migrating outright below that line custom integration is

265
00:15:33,140 --> 00:15:38,340
annoying but survivable above it every acquisition adds another layer of reconciliation work

266
00:15:38,340 --> 00:15:42,900
another set of mappings another place for something to quietly break during close that's the real

267
00:15:42,900 --> 00:15:47,860
trigger hiding behind we made an acquisition it's not the acquisition itself it's what acquisitions

268
00:15:47,860 --> 00:15:52,500
due to the math compounding a manageable integration problem into one that costs more to maintain than

269
00:15:52,500 --> 00:15:57,460
to replace which raises the obvious next question what does that patchwork actually look like while

270
00:15:57,460 --> 00:16:03,940
a company is still holding it together month after month close after close inside the patchwork

271
00:16:03,940 --> 00:16:08,500
data verse and dual write start with data verse because everything else in this section depends

272
00:16:08,500 --> 00:16:13,540
on getting that piece right data verse is a shared data layer think of it as a common storage space

273
00:16:13,540 --> 00:16:18,420
that different Microsoft business apps can write to and read from so a customer record created in one

274
00:16:18,420 --> 00:16:23,300
app can show up in another without somebody manually retyping it sales customer service business

275
00:16:23,300 --> 00:16:27,860
central finance and operations they can all point at the same underlying data instead of keeping

276
00:16:27,860 --> 00:16:31,860
five separate copies that drift apart over time that's the concept now here's where most

277
00:16:31,860 --> 00:16:36,340
explanations of this go wrong and where the confusion actually starts costing companies money

278
00:16:36,340 --> 00:16:40,980
dual write is a specific piece of Microsoft's integration plumbing and it does something real

279
00:16:40,980 --> 00:16:46,660
near real time two way sink built specifically to connect finance and operations with customer engagement

280
00:16:46,660 --> 00:16:52,020
apps like sales change a customer's payment terms in FNO and that change shows up in sales within

281
00:16:52,020 --> 00:16:56,980
seconds not hours that's genuinely useful and it's genuinely well built here's the correction that

282
00:16:56,980 --> 00:17:01,620
matters the one that trips up almost every it leader looking at this from the outside dual write

283
00:17:01,620 --> 00:17:06,820
was not built for business central business central runs its own separate data verse sink mechanism

284
00:17:06,820 --> 00:17:11,300
a different piece of engineering entirely doing a similar job but through a completely different

285
00:17:11,300 --> 00:17:15,700
pipe so what does that actually mean once you're running BC in your subsidiaries in FNO at headquarters

286
00:17:15,700 --> 00:17:20,660
it means there is no single dual write map spanning both systems none you're not flipping one switch

287
00:17:20,660 --> 00:17:25,380
and watching data flow cleanly between BC and FNO through one unified integration layer you're

288
00:17:25,380 --> 00:17:29,540
stitching together two separate integration systems that were never designed to talk to each other

289
00:17:29,540 --> 00:17:35,140
in the first place one built for FNOs world and one build for BCs and then building the connective

290
00:17:35,140 --> 00:17:39,460
tissue between them yourself that distinction sounds technical until you hit the part that actually

291
00:17:39,460 --> 00:17:45,140
changes how your business runs day to day timing BC's data verse sink jobs run on a schedule not in real

292
00:17:45,140 --> 00:17:50,660
time default configuration checks every 30 minutes if nothing's changed the drop can go quiet for up to

293
00:17:50,660 --> 00:17:56,100
12 hours before it checks again for a single company running one business central instance with nobody

294
00:17:56,100 --> 00:18:00,900
outside that instance waiting on the data that delay doesn't matter nobody's checking a dashboard

295
00:18:00,900 --> 00:18:05,380
every 90 seconds waiting for a customer record to refresh change the picture to a subsidiary running

296
00:18:05,380 --> 00:18:11,300
BC while headquarters runs FNO and that same 30-minute to 12-hour window turns into a liability

297
00:18:11,300 --> 00:18:16,580
finance can actually feel headquarters need same-day numbers from a subsidiary closing out a busy

298
00:18:16,580 --> 00:18:21,300
sales day instead they're looking at whatever synced last which might be current or might be sitting

299
00:18:21,300 --> 00:18:25,540
12 hours stale depending on when the last change happened to trigger the job nobody planned for

300
00:18:25,540 --> 00:18:30,580
that gap it just showed up baked into the default behavior of a sync mechanism most people assumed

301
00:18:30,580 --> 00:18:35,140
worked like the near real time dual right they'd heard about somewhere else here's the point worth

302
00:18:35,140 --> 00:18:39,860
sitting with before moving forward from a distance all of this looks like integration data moves

303
00:18:39,860 --> 00:18:44,740
between systems dashboards populate reports pull numbers from more than one source it looks clean on

304
00:18:44,740 --> 00:18:49,060
a slide look closer and what you actually find is two different plumbing systems each build for a

305
00:18:49,060 --> 00:18:53,220
different product each running on its own schedule with its own assumptions connected at the

306
00:18:53,220 --> 00:18:58,500
joints by whatever custom work somebody had to build to bridge the gap Microsoft never closed

307
00:18:58,500 --> 00:19:03,060
that's not integration in the sense most leadership teams picture when they hear the word it's duct tape

308
00:19:03,060 --> 00:19:07,700
applied carefully holding two systems together that were never meant to share a pipeline the one

309
00:19:07,700 --> 00:19:12,820
way street how GL data actually moves strip away the terminology and here's what actually happens

310
00:19:12,820 --> 00:19:18,420
with the money general ledger data moves in one direction from business central up to finance and

311
00:19:18,420 --> 00:19:23,060
operations not both ways not a living breathing sync where either system can update the other one

312
00:19:23,060 --> 00:19:28,420
direction BC to FNO full stop and it doesn't move continuously it moves on a schedule a batch job

313
00:19:28,420 --> 00:19:33,460
that runs daily or weekly depending on how somebody configured it pulling a defined set of transactions

314
00:19:33,460 --> 00:19:38,660
out of BC and pushing them into FNO's consolidation layer that's the mechanism nobody's watching a

315
00:19:38,660 --> 00:19:42,900
live feed of subsidiary transactions landing at headquarters the instant they post here's what that

316
00:19:42,900 --> 00:19:47,860
actually means for the people staring at a dashboard headquarters running FNO is looking at yesterday's

317
00:19:47,860 --> 00:19:52,820
numbers from the subsidiary not this morning's numbers not right now numbers whatever batch job ran

318
00:19:52,820 --> 00:19:57,220
last on whatever scheduled somebody said months ago usually overnight sometimes less often than that

319
00:19:57,220 --> 00:20:01,780
if the subsidiary closed a major sale at four in the afternoon headquarters isn't seeing it reflected

320
00:20:01,780 --> 00:20:06,340
in consolidated figures until the next batch cycle runs and depending on the schedule that might not be

321
00:20:06,340 --> 00:20:12,020
until the following day during a normal month that lag is an inconvenience during month and close

322
00:20:12,020 --> 00:20:16,500
it compounds into something worse reconciliation happens against data that's already a day or two

323
00:20:16,500 --> 00:20:20,980
stale by the time anyone's looking at it someone at headquarters flags a discrepancy someone at the

324
00:20:20,980 --> 00:20:25,940
subsidiary investigates and by the time the answer comes back another batch cycle has already run

325
00:20:25,940 --> 00:20:31,700
and shifted the numbers again corrections happen after the fact layered on top of numbers that were

326
00:20:31,700 --> 00:20:35,460
already layered on top of the numbers before them close doesn't get faster with more systems in

327
00:20:35,460 --> 00:20:40,020
play it gets slower one batch job at a time now put that against what gets promised somewhere in

328
00:20:40,020 --> 00:20:45,220
a sales conversation months before any of this integration work starts real time visibility across

329
00:20:45,220 --> 00:20:49,460
the business one dashboard current numbers leadership making decisions of what's actually

330
00:20:49,460 --> 00:20:53,540
happening right now instead of what happened yesterday that promise isn't a lie exactly it's just

331
00:20:53,540 --> 00:20:58,500
built on an assumption that never gets stated out loud it assumes one system it assumes everyone's

332
00:20:58,500 --> 00:21:03,140
data lives in the same database updating the same tables visible the instant it posts the moment

333
00:21:03,140 --> 00:21:07,300
you're running two systems instead of one real time visibility isn't a feature you're missing

334
00:21:07,300 --> 00:21:11,540
it's a promise that was only ever true for a version of your business that doesn't exist anymore

335
00:21:11,540 --> 00:21:15,380
eventually somebody stops accepting the lag as a cost of doing business and starts running the

336
00:21:15,380 --> 00:21:20,420
actual math not a gut feeling about whether the patchwork is annoying a real comparison what is

337
00:21:20,420 --> 00:21:25,300
holding this together keep costing month after month against what it would cost to just migrate and

338
00:21:25,300 --> 00:21:30,820
be done with the seams entirely the break even point when patchwork costs more than migration

339
00:21:30,820 --> 00:21:34,900
this isn't a decision that gets made in a meeting it gets made on a spreadsheet quietly usually

340
00:21:34,900 --> 00:21:40,020
by someone in finance who finally sat down and added up what the patchwork actually costs every month

341
00:21:40,020 --> 00:21:45,140
instead of just feeling the pain of it during close list out what the patchwork actually charges you

342
00:21:45,140 --> 00:21:49,380
integration maintenance the ongoing work of keeping the sync jobs running and fixing them when

343
00:21:49,380 --> 00:21:54,900
they break custom elimination logic built once but never finished because every new acquisition adds

344
00:21:54,900 --> 00:21:59,620
another mapping another edge case another reconciliation rule someone has to write and test i.t

345
00:21:59,620 --> 00:22:04,100
headcount babysitting sync jobs that were supposed to run themselves delayed closes month after month

346
00:22:04,100 --> 00:22:09,060
that push finance further behind schedule every quarter ordered friction because every auditor who

347
00:22:09,060 --> 00:22:13,300
touches this environment has to trace a transaction across three separate logs before they can

348
00:22:13,300 --> 00:22:17,940
sign off on anything none of these show up as one line item they hide in different budgets different

349
00:22:17,940 --> 00:22:22,740
departments different headcount requests that never get compared against each other directly now put

350
00:22:22,740 --> 00:22:27,060
migration on the other side of that ledger a phased business central to finance and operations

351
00:22:27,060 --> 00:22:31,540
project runs 12 to 18 months that's real money real disruption a real line item that makes a

352
00:22:31,540 --> 00:22:36,420
CFO wins the first time they see the number but here's what actually happens when organizations run

353
00:22:36,420 --> 00:22:41,460
this comparison honestly side by side instead of comparing a monthly patchwork cost against a

354
00:22:41,460 --> 00:22:47,060
headline migration number that looks scary in isolation migrating consolidation entirely into finance

355
00:22:47,060 --> 00:22:51,620
and operations frequently ends up cheaper than maintaining a fragile multi-system integration

356
00:22:51,620 --> 00:22:55,700
indefinitely not because migration is cheap because indefinitely is a long time and every

357
00:22:55,700 --> 00:23:00,260
month the patchwork survives it adds another month of maintenance cost another acquisitions worth

358
00:23:00,260 --> 00:23:05,620
of new mapping work another quarter of a close that runs longer than it should here's the part nobody

359
00:23:05,620 --> 00:23:09,620
wants to say out loud and it's worth naming directly because it's the real reason companies wait

360
00:23:09,620 --> 00:23:14,660
past the point where the math already flipped sunk cost leadership spent years building that integration

361
00:23:14,660 --> 00:23:19,140
they spent real money getting the sync jobs configured getting the elimination logic custom

362
00:23:19,140 --> 00:23:23,540
built training a team to babysit all of it admitting that the whole thing needs to be replaced feels

363
00:23:23,540 --> 00:23:27,780
like admitting the years and the money were wasted like standing up in front of the board and saying

364
00:23:27,780 --> 00:23:31,860
the plan everyone signed off on was wrong it wasn't wrong that's worth saying plainly because it

365
00:23:31,860 --> 00:23:36,820
isn't failure it's a system reaching the edge of what it was ever built to carry business central

366
00:23:36,820 --> 00:23:41,540
wasn't designed to hold five acquisitions together forever nobody failed by building a patchwork

367
00:23:41,540 --> 00:23:46,660
that worked for three years the patchwork did its job it bought time eventually time runs out

368
00:23:46,660 --> 00:23:51,140
and the math on the spreadsheet says so before anyone in the room is ready to hear it if migration

369
00:23:51,140 --> 00:23:56,420
becomes the answer once that math lands the next question is what that migration actually asks of

370
00:23:56,420 --> 00:24:01,060
the organization because migration is about to turn out to be the wrong word for what's coming

371
00:24:01,060 --> 00:24:07,620
why migration is the wrong word say it plainly moving from business central to finance and operations

372
00:24:07,620 --> 00:24:12,580
is not a migration in the way naev to bc was a migration that word carries baggage it hasn't earned

373
00:24:12,580 --> 00:24:17,460
here and the baggage is exactly what sets budgets and timelines wrong from day one look at what naev

374
00:24:17,460 --> 00:24:23,700
to bc actually was because it's the closest comparison most it leaders have in their heads same lineage

375
00:24:23,700 --> 00:24:28,180
same underlying logic running under the hood customizations got rebuilt as extensions instead of full

376
00:24:28,180 --> 00:24:32,580
ground up rebuilds and data carried forward with the conversion process that while not trivial

377
00:24:32,580 --> 00:24:37,220
worked within a shared set of assumptions about how a ledger entry behaves and how a dimension

378
00:24:37,220 --> 00:24:43,700
gets tagged naev to bc stayed inside one family different furniture same house bc to fn o crosses

379
00:24:43,700 --> 00:24:48,420
align naev to bc never came close to different table structures built by different teams in different

380
00:24:48,420 --> 00:24:52,900
decades for different scales of business entirely different posting logic meaning a transaction

381
00:24:52,900 --> 00:24:57,540
doesn't just look different it behaves differently once it lands different account frameworks

382
00:24:57,540 --> 00:25:02,340
meaning even the concept of what a chart of accounts is capable of expressing changes underneath you

383
00:25:02,340 --> 00:25:06,420
this isn't a bigger house with the same furniture it's a different foundation a different frame

384
00:25:06,420 --> 00:25:11,140
a different set of load bearing walls so walk through what actually happens once you strip the label

385
00:25:11,140 --> 00:25:16,660
migration off and look at the real steps underneath first extraction pulling data out of business

386
00:25:16,660 --> 00:25:21,620
central in a form that means something once it's no longer sitting inside bc's own internal logic

387
00:25:21,620 --> 00:25:27,780
second transformation reshaping that extracted data to fit a schema that was never designed with

388
00:25:27,780 --> 00:25:32,340
bc's structure in mind translating concepts that don't have a clean one-to-one equivalent on the

389
00:25:32,340 --> 00:25:38,900
other side third loading pushing that transform data into finance and operations using fn o's own

390
00:25:38,900 --> 00:25:43,940
data management tools tools build assuming enterprise grade structure walks in the door not small

391
00:25:43,940 --> 00:25:49,380
business simplicity fourth validation checking every number every account every balance confirming

392
00:25:49,380 --> 00:25:54,580
what landed on the fn o side actually matches what left business central line by line with no short cuts

393
00:25:54,580 --> 00:26:00,500
each of those four steps is a project in its own right not a phase inside one tidy migration plan

394
00:26:00,500 --> 00:26:05,460
not a checkbox somebody takes off on a Friday afternoon extraction alone can surface data quality

395
00:26:05,460 --> 00:26:09,700
problems nobody knew existed transformation alone can take weeks once you hit the accounts that

396
00:26:09,700 --> 00:26:14,740
don't map cleanly loading alone requires someone who actually understands fn o's data management

397
00:26:14,740 --> 00:26:19,220
framework well enough not to break something on the way in validation alone means somebody sits

398
00:26:19,220 --> 00:26:23,780
with two sets of numbers and refuses to sign off until they match which sometimes takes longer

399
00:26:23,780 --> 00:26:29,220
than anyone budgeted for calling this a migration under cells it's so badly that the damage starts

400
00:26:29,220 --> 00:26:33,780
before the project even kicks off it sets a budget sized for moving furniture when what's actually

401
00:26:33,780 --> 00:26:38,580
required is pouring a new foundation it sets a timeline sized for software upgrade when what's

402
00:26:38,580 --> 00:26:42,420
actually required is four separate projects stacked on top of each other each with its own way

403
00:26:42,420 --> 00:26:48,980
of going wrong the word itself is where the mistake begins business process redesign not data transfer

404
00:26:48,980 --> 00:26:54,100
everything up to this point has been about data extraction transformation loading validation

405
00:26:55,060 --> 00:27:00,020
necessary work expensive work but not the hardest work the hardest work is process and almost nobody

406
00:27:00,020 --> 00:27:04,420
budgets for it the way they should business central approval workflows its posting groups its

407
00:27:04,420 --> 00:27:09,140
dimensions none of that maps cleanly onto how finance and operations expects a business to run

408
00:27:09,140 --> 00:27:13,220
these aren't cosmetic differences you patch with a settings change they're different philosophies

409
00:27:13,220 --> 00:27:17,380
about how work should move through an organization and every team that touches the ERP

410
00:27:17,380 --> 00:27:22,260
has to unlearn one philosophy and pick up the other take procurement because it shows the gap

411
00:27:22,260 --> 00:27:27,460
clearly in business central a purchase starts on a requisition worksheet someone flags a need

412
00:27:27,460 --> 00:27:32,100
roots it through an approval chain and a purchase order comes out the other side simple direct

413
00:27:32,100 --> 00:27:36,260
built for a company where procurement doesn't need much ceremony finance and operations runs a

414
00:27:36,260 --> 00:27:40,820
completely different model full requisition management with punch out capability that connects

415
00:27:40,820 --> 00:27:45,300
directly into supplier catalogs multi-stage approval routing that can vary by category or

416
00:27:45,300 --> 00:27:50,020
spend threshold demand planning tied into the request before it even becomes a formal purchase

417
00:27:50,020 --> 00:27:54,100
that's not the same process running on a different screen it's a different answer to the question

418
00:27:54,100 --> 00:27:58,420
of what procurement is supposed to accomplish built for organizations where a thousand requisitions

419
00:27:58,420 --> 00:28:03,620
a month is normal and a single mis-approval step can mean a compliance problem manufacturing splits

420
00:28:03,620 --> 00:28:08,580
the same way business central handles discrete manufacturing full stop build a defined product

421
00:28:08,580 --> 00:28:13,620
from a bill of materials run it through a production order done finance and operations handles

422
00:28:13,620 --> 00:28:17,620
discrete manufacturing and process manufacturing both because enterprise operations often need to

423
00:28:17,620 --> 00:28:22,500
track a batch of chemicals or a continuous production run alongside a discrete assembly line sometimes

424
00:28:22,500 --> 00:28:27,940
in the same facility a manufacturing team that's only ever configured discrete workflows in BC

425
00:28:27,940 --> 00:28:32,660
is walking into a system that assumes it might need to handle both and figuring out which parts of

426
00:28:32,660 --> 00:28:38,580
that apply takes real time not a quick orientation session this is the part that gets missed in almost

427
00:28:38,580 --> 00:28:43,060
every planning conversation it isn't just finance that has to relearn its process it's every team

428
00:28:43,060 --> 00:28:47,860
that touches the ERP procurement has to relearn what a requisition actually is inside the system

429
00:28:47,860 --> 00:28:52,500
manufacturing has to relearn how a production order gets structured sales has to relearn

430
00:28:52,500 --> 00:28:57,220
how pricing and order management behave under F&O's more elaborate rules nobody gets to keep

431
00:28:57,220 --> 00:29:00,900
doing their job the exact same way with new buttons and new places they're learning a different

432
00:29:00,900 --> 00:29:05,220
set of assumptions about how their own work is supposed to flow that's the real reason F&O

433
00:29:05,220 --> 00:29:09,860
implementations run six to 18 months and it's worth saying directly because most people assume

434
00:29:09,860 --> 00:29:15,460
the length comes from slower software rollout more servers to configure more testing cycles to run

435
00:29:15,460 --> 00:29:20,100
it isn't that it's organizational relearning spread across every department that depends on the

436
00:29:20,100 --> 00:29:25,700
system to do its job you can extract and transform data in a few focused sprints you cannot compress

437
00:29:25,700 --> 00:29:29,540
the time it takes an entire procurement team to internalize a different approval philosophy or

438
00:29:29,540 --> 00:29:33,860
a manufacturing team to reconfigure how it thinks about a production order none of this holds

439
00:29:33,860 --> 00:29:38,740
together though if what's underneath it is a mess a redesigned process running on top of duplicate

440
00:29:38,740 --> 00:29:43,380
vendor records and unreconsiled balances doesn't fix anything it just gives the mess a new interface

441
00:29:43,380 --> 00:29:49,700
to hide behind the data cleanup nobody budgets for most disruption at go live doesn't come from the

442
00:29:49,700 --> 00:29:54,260
problems everyone sees coming it comes from the small undocumented ones nobody thought to mention

443
00:29:54,260 --> 00:29:58,260
because nobody remembered they existed until something broke duplicate vendor records that got

444
00:29:58,260 --> 00:30:03,140
created twice years apart by two different people who didn't know the other one had already set it

445
00:30:03,140 --> 00:30:08,500
up unreconsiled balances sitting quietly on a sub ledger never causing a visible problem because nobody

446
00:30:08,500 --> 00:30:12,980
was looking closely enough to notice customizations somebody built five years ago solved a real problem

447
00:30:12,980 --> 00:30:17,540
at the time and then got forgotten the moment the person who built it left the company none of these

448
00:30:17,540 --> 00:30:21,540
show up on a project plan all of them show up the week after go live usually during the first

449
00:30:21,540 --> 00:30:25,860
close usually at the worst possible time here's the thing worth correcting directly because it's

450
00:30:25,860 --> 00:30:30,100
the opposite of what most people worry about going in the risk was never bringing too little data

451
00:30:30,100 --> 00:30:34,260
across nobody's implementation fails because they forgot to migrate something small the risk is

452
00:30:34,260 --> 00:30:40,020
bringing dirty data across cleanly formatted perfectly extracted transformed and loaded exactly as

453
00:30:40,020 --> 00:30:45,060
instructed and still wrong because the mess was already baked into the source system before anyone

454
00:30:45,060 --> 00:30:49,860
touched it so the discipline that actually protects the migration starts before extraction even

455
00:30:49,860 --> 00:30:55,060
begins retain a defined window of historical data typically no more than seven years and archive

456
00:30:55,060 --> 00:30:59,620
the rest somewhere it stays accessible for audit purposes without cluttering the new system that's not

457
00:30:59,620 --> 00:31:04,660
a data limitation it's a decision made on purpose about what actually needs to live inside the live

458
00:31:04,660 --> 00:31:10,340
environment versus what just needs to exist somewhere retrievable the harder discipline is customizations

459
00:31:10,340 --> 00:31:15,620
and this is where most teams underestimate the work by an order of magnitude every custom field

460
00:31:15,620 --> 00:31:20,340
every workflow tweak built into the old business central environment needs to go through the same

461
00:31:20,340 --> 00:31:25,540
classification exercise one by one with no exceptions made for the ones that feel too small to bother with

462
00:31:25,540 --> 00:31:30,180
rebuild it as something equivalent inside FNO replace it with a native feature that already does the

463
00:31:30,180 --> 00:31:34,580
job better than the custom version ever did find an equivalent app that solves the same problem without

464
00:31:34,580 --> 00:31:39,300
custom code or retire it entirely because half the time nobody using the system today actually

465
00:31:39,300 --> 00:31:43,540
needs what it was built to do that classification work sounds administrative it isn't it's the difference

466
00:31:43,540 --> 00:31:47,940
between a go live that surfaces a handful of known gaps the team already planned around and a go

467
00:31:47,940 --> 00:31:52,980
live that surfaces a dozen surprises nobody had time to prepare for because nobody wrote them down

468
00:31:52,980 --> 00:31:57,700
when they still could have the migrations that fail aren't failing on the big visible stuff extraction

469
00:31:57,700 --> 00:32:02,900
gets planned transformation gets planned loading gets planned what syncs a project is the stuff nobody

470
00:32:02,900 --> 00:32:07,620
wrote down sitting quietly in a corner of the old system waiting for someone to trip over it during

471
00:32:07,620 --> 00:32:13,380
the one week everyone least wants surprises what gets left behind not everything comes over and

472
00:32:13,380 --> 00:32:17,940
that's by design not failure a clean migration doesn't mean carrying every piece of the old system

473
00:32:17,940 --> 00:32:22,740
forward and setting it down gently inside the new one it means deciding on purpose what actually

474
00:32:22,740 --> 00:32:27,140
deserves a seat at the table in FNO and what stays behind because it never needed to make the trip

475
00:32:27,140 --> 00:32:31,540
old custom code is the clearest case something written years ago to solve a problem specific to

476
00:32:31,540 --> 00:32:36,180
business central structure built around BC's tables BC's event model BC's way of extending a

477
00:32:36,180 --> 00:32:41,860
process often has no equivalent in FNO's architecture at all not a worse version not a simplified

478
00:32:41,860 --> 00:32:46,980
version no version because the problem it solved either doesn't exist inside FNO design or gets

479
00:32:46,980 --> 00:32:51,300
handled by a completely different mechanism nobody thought to compare it against trying to force

480
00:32:51,300 --> 00:32:55,540
that old code into the new environment doesn't preserve anything it just recreates a work around

481
00:32:55,540 --> 00:32:59,300
for a problem the new system was never going to have in the first place reports carry the same

482
00:32:59,300 --> 00:33:03,460
trap and it's a common one because reports feel like they should just move they don't a report

483
00:33:03,460 --> 00:33:07,780
built against business central data model isn't something you re-point at a new data source and call

484
00:33:07,780 --> 00:33:13,300
finished the underlying schema is different the tables don't line up the fields that used to sit next

485
00:33:13,300 --> 00:33:17,540
to each other don't live in the same place anymore every report that matters has to get rebuilt against

486
00:33:17,540 --> 00:33:22,500
FNO's schema from the ground up not patched not redirected anyone who budgets for reporting as a

487
00:33:22,500 --> 00:33:27,140
quick fix during migration finds that out the hard way usually right when finance asks for the first

488
00:33:27,140 --> 00:33:31,940
month and report and nobody can produce it historical data gets its own answer to separate from

489
00:33:31,940 --> 00:33:36,340
what's been said about retention windows some of it simply stays where it is the old business central

490
00:33:36,340 --> 00:33:41,940
environment gets kept in read only mode accessible for audit purposes for 12 to 24 months at minimum

491
00:33:41,940 --> 00:33:46,100
so anyone who needs to trace something back to a transaction from before cut over still can

492
00:33:46,100 --> 00:33:51,140
without cluttering the live FNO environment with data nobody's actively working against anymore

493
00:33:51,140 --> 00:33:55,780
here's the reframe worth holding on to a migration that drags every piece of old baggage forward

494
00:33:55,780 --> 00:34:00,660
every dead customization every report nobody rebuilt properly every scrap of history that could

495
00:34:00,660 --> 00:34:06,020
have stayed archived isn't a clean start it's just moving the same mess into a more expensive system

496
00:34:06,020 --> 00:34:10,580
and paying enterprise grade licensing to keep storing it which raises a fair question one that's

497
00:34:10,580 --> 00:34:15,060
been sitting underneath this entire conversation if the wall is this real this structural this expensive

498
00:34:15,060 --> 00:34:19,380
to cross why does anyone build on business central in the first place knowing growth might run

499
00:34:19,380 --> 00:34:25,300
them straight into it the case for starting on bc anyway fair question and it deserves a straight

500
00:34:25,300 --> 00:34:29,220
answer instead of a hedge does all of this mean business central was a bad choice from the start some

501
00:34:29,220 --> 00:34:34,020
kind of trap dressed up as an entry point no and the reason matters more than the denial itself

502
00:34:34,020 --> 00:34:40,020
bc speed and cost make it the right start for the size a company actually is today not the size

503
00:34:40,020 --> 00:34:44,740
it might become in a scenario that hasn't happened yet and might never happen at all three to six

504
00:34:44,740 --> 00:34:49,540
months to implement against six to eighteen eighty dollars a user against two hundred that gap

505
00:34:49,540 --> 00:34:53,940
isn't a rounding error when cash is tight when a finance team is small enough that one person

506
00:34:53,940 --> 00:34:58,740
wears three hats that difference in cost and speed is the difference between getting a working system

507
00:34:58,740 --> 00:35:03,700
live this year or spending 18 months in a budget the company doesn't have chasing enterprise

508
00:35:03,700 --> 00:35:08,580
features nobody on staff would even use yet here's what gets missed in most of these conversations

509
00:35:08,580 --> 00:35:13,220
and it's worth saying plainly most companies that start on business central never hit the F&O wall

510
00:35:13,220 --> 00:35:17,860
not because they got lucky because most companies simply don't do the kind of multi entity multi

511
00:35:17,860 --> 00:35:22,420
country growth that triggers the collision in the first place they grow they add customers add

512
00:35:22,420 --> 00:35:27,140
revenue add head count they don't add a second legal entity in another country or acquire a

513
00:35:27,140 --> 00:35:32,980
competitor running a different ERP or find themselves suddenly answerable to a board that once one

514
00:35:32,980 --> 00:35:39,140
consolidated number across five subsidiaries growth in scale and growth in shape are two different things

515
00:35:39,140 --> 00:35:43,940
and only one of them runs you into this particular wall so the mistake was never choosing business

516
00:35:43,940 --> 00:35:48,260
central the mistake is assuming business central was designed to carry a company past that specific

517
00:35:48,260 --> 00:35:52,580
growth pattern without any plan for what happens if it shows up nobody picks bc and gets punished

518
00:35:52,580 --> 00:35:57,860
for picking bc companies get hurt when they pick bc grow in exactly the shape that breaks it

519
00:35:57,860 --> 00:36:02,820
and never once stop to ask what happens if that shape of growth actually arrives here's the

520
00:36:02,820 --> 00:36:08,020
point worth landing before moving forward business central is the right tool for a real common size

521
00:36:08,020 --> 00:36:11,940
and shape of business the kind that makes up the overwhelming majority of companies that will

522
00:36:11,940 --> 00:36:17,140
ever touch this ecosystem the trap doesn't spring because a company grew it springs when growth

523
00:36:17,140 --> 00:36:21,700
changes the shape of the business not just the size of it multiple entities multiple countries

524
00:36:21,700 --> 00:36:27,220
consolidation demands nobody architected for and the company walks into that shift without having

525
00:36:27,220 --> 00:36:31,620
asked the question early enough to matter that's the real dividing line dot bc versus F&O growth

526
00:36:31,620 --> 00:36:37,540
you plan for versus growth you didn't designing for the size you'll become so the question shifts

527
00:36:37,540 --> 00:36:42,100
not did we pick the right system but what do we do differently starting now if we're the kind of

528
00:36:42,100 --> 00:36:46,900
company that might grow into this shape someday start with the chart of accounts because this is the

529
00:36:46,900 --> 00:36:51,780
cheapest place to plan and the most expensive place to fix later build it and the dimension structure

530
00:36:51,780 --> 00:36:56,340
underneath it with consolidation in mind even when you're running one entity and consolidation isn't

531
00:36:56,340 --> 00:37:00,820
a problem yet that doesn't mean over complicating a simple business that means choosing account

532
00:37:00,820 --> 00:37:04,740
structures and dimension values that wouldn't need to be torn apart if a second entity showed up next

533
00:37:04,740 --> 00:37:09,380
year a little discipline here costs almost nothing today untangling a chart of accounts that grew

534
00:37:09,380 --> 00:37:15,060
organically with no plan three acquisitions deep costs real money and real time next figure out

535
00:37:15,060 --> 00:37:19,300
early which pieces of data will eventually need to cross a system boundary because some data

536
00:37:19,300 --> 00:37:24,660
always does the moment a company grows in shape rather than just size customer master vendor master

537
00:37:24,660 --> 00:37:28,740
product master the GL structure itself these are the records that end up living in two places at

538
00:37:28,740 --> 00:37:33,460
once the day an acquisition happens and deciding now how they're structured named and coded is a

539
00:37:33,460 --> 00:37:38,820
lot cheaper than reverse engineering consistency across five years of inconsistent entry after the

540
00:37:38,820 --> 00:37:43,140
fact that's where data verse belongs in this conversation not as something you bolt on in a panic

541
00:37:43,140 --> 00:37:48,100
after acquisition number two but as a possible shared layer you at least architect award from the

542
00:37:48,100 --> 00:37:52,580
start you don't need to build the full integration today you do need to avoid building master data

543
00:37:52,580 --> 00:37:58,420
in a way that makes a shared layer impossible later as we saw earlier BC and FNO each connect

544
00:37:58,420 --> 00:38:02,820
to data verse through their own separate mechanisms planning for that reality now instead of

545
00:38:02,820 --> 00:38:07,300
discovering admit crisis is the difference between an integration project and an integration

546
00:38:07,300 --> 00:38:12,020
emergency and then there's the discipline almost nobody keeps the one that costs nothing but

547
00:38:12,020 --> 00:38:17,860
attention document every customization the day it gets built not five years later when someone

548
00:38:17,860 --> 00:38:22,260
new joins the team and asks what a field does and nobody left can answer not during a migration when

549
00:38:22,260 --> 00:38:26,500
a classification exercise turns into archaeology the day it's built while the person who built it

550
00:38:26,500 --> 00:38:31,300
still remembers why none of this means overbuilding for a future that might not arrive most companies

551
00:38:31,300 --> 00:38:35,140
on business central will never need any of this the point isn't to architect like an acquisition is

552
00:38:35,140 --> 00:38:39,940
coming it's to leave the door unlocked instead of welding it shut so that if growth does change

553
00:38:39,940 --> 00:38:44,340
shape instead of just size the company isn't starting from zero that's the theory it stays theory

554
00:38:44,340 --> 00:38:48,420
until a company actually goes through it until the acquisition lands on a Monday morning and

555
00:38:48,420 --> 00:38:52,900
someone has to make these decisions under a deadline instead of in a planning session with time to

556
00:38:52,900 --> 00:38:59,460
think a realistic M&A scenario walkthrough here's how this actually plays out start to finish in a

557
00:38:59,460 --> 00:39:05,460
scenario built from the pattern that keeps repeating across companies that hit this wall a mid-size

558
00:39:05,460 --> 00:39:11,700
company runs business central solid operation clean books one entity one country it acquires a competitor

559
00:39:11,700 --> 00:39:16,900
similar size also running business central but in a different country entirely different tax rules

560
00:39:16,900 --> 00:39:22,260
different currency different chart of accounts built by a different consultant years ago with no

561
00:39:22,260 --> 00:39:26,820
coordination between the two the intention coming out of the deal is simple to state and hard to

562
00:39:26,820 --> 00:39:31,380
deliver close the acquisition then report combined numbers to the board within one quarter

563
00:39:31,380 --> 00:39:35,700
leadership wants to show the market this deal is already paying off one number combined revenue

564
00:39:35,700 --> 00:39:40,660
combine margin one story instead of two the obstacle shows up almost immediately two separate

565
00:39:40,660 --> 00:39:45,780
business central databases running independently with no shared connection between them two charts of

566
00:39:45,780 --> 00:39:49,940
accounts that don't map on to each other cleanly because nobody built them with the other one in

567
00:39:49,940 --> 00:39:54,740
mind and underneath both of those something worse two different definitions of what actually counts

568
00:39:54,740 --> 00:39:59,300
is revenue recognition one entity recognizes revenue on shipment the other recognizes it on

569
00:39:59,300 --> 00:40:03,380
invoice nobody notices this mismatch until someone tries to add the two together and the combined

570
00:40:03,380 --> 00:40:07,860
number doesn't reconcile against either underlying system there's no time to architect anything proper

571
00:40:07,860 --> 00:40:11,540
before that first board update is due so the stopgap is the one every company reaches for

572
00:40:11,540 --> 00:40:16,820
under deadline pressure manual consolidation in spreadsheets someone on the finance team pulls

573
00:40:16,820 --> 00:40:21,860
exports from both BC instances maps the accounts by hand adjust for the revenue recognition gap

574
00:40:21,860 --> 00:40:27,540
manually and builds a combined view good enough to present it works barely and it buys time nobody

575
00:40:27,540 --> 00:40:32,820
realizes is actually being spent six months in the spreadsheet process starts breaking down in the

576
00:40:32,820 --> 00:40:38,260
way these things always do quietly at first transaction volume grows past what a manual process can

577
00:40:38,260 --> 00:40:43,540
absorb without cracks showing the manual mapping that worked fine at low volume starts missing things

578
00:40:43,540 --> 00:40:48,420
at higher volume errors creep into board reporting small at first a mismatched account here a

579
00:40:48,420 --> 00:40:53,220
rounding issue there then large enough that someone on the board asks a question finance can't answer

580
00:40:53,220 --> 00:40:57,460
cleanly in the meeting this is the exact moment the finance and operations conversation starts

581
00:40:57,460 --> 00:41:03,300
getting set out loud not as a theoretical someday but as an actual line item on someone's task list

582
00:41:03,300 --> 00:41:07,700
and it's the exact moment the there's no direct path reality lands with full weight because up

583
00:41:07,700 --> 00:41:12,100
until this point most of the people in the room assumed a bridge existed somewhere now they're

584
00:41:12,100 --> 00:41:17,300
finding out otherwise mid crisis with a board already asking uncomfortable questions the resolution

585
00:41:17,300 --> 00:41:21,700
that actually works isn't a switch flip it's a face plan business central stays live in both

586
00:41:21,700 --> 00:41:26,180
subsidiaries during the transition because ripping it out immediately would break operations nobody

587
00:41:26,180 --> 00:41:31,300
has time to rebuild under pressure finance and operations comes in first as the consolidation and

588
00:41:31,300 --> 00:41:36,740
reporting layer sitting above both BC instances giving the board one number without requiring either

589
00:41:36,740 --> 00:41:43,300
subsidiary to change how it works day to day full migration into FNO follows later over 12 to 18 months

590
00:41:43,300 --> 00:41:47,620
once the business has stabilized enough to absorb a project of that size without breaking something

591
00:41:47,620 --> 00:41:52,980
else in the process the faced path that actually works lay that scenario next to the fantasy version

592
00:41:52,980 --> 00:41:57,860
most people picture when they first hear we're moving to FNO and the gap is obvious nobody flips

593
00:41:57,860 --> 00:42:02,180
a switch on a Friday and wakes up Monday with one clean system what actually works is slower less

594
00:42:02,180 --> 00:42:06,580
dramatic and comes in four phases that each have to finish before the next one starts making sense

595
00:42:07,060 --> 00:42:12,260
phase one stabilize each business central instance on its own before anyone touches integration

596
00:42:12,260 --> 00:42:16,900
clean the data inside each subsidiary document every customization sitting in each environment

597
00:42:16,900 --> 00:42:21,540
the same classification discipline covered earlier applied separately to each BC instance rather

598
00:42:21,540 --> 00:42:26,260
than assume to be consistent across them this step gets skipped constantly because it feels like

599
00:42:26,260 --> 00:42:30,660
standing still while the real work waits it isn't standing still two clean systems are easier to

600
00:42:30,660 --> 00:42:35,300
connect than two messy ones and building integration on top of unresolved data problems just moves

601
00:42:35,300 --> 00:42:41,060
the mess one layer up phase two build the data verse and integration layer for shared master data as

602
00:42:41,060 --> 00:42:45,460
we covered earlier BC and FNO each connect to data verse through their own separate mechanisms

603
00:42:45,460 --> 00:42:49,860
and the sink cadence runs on a schedule not in real time go into this phase already knowing that

604
00:42:49,860 --> 00:42:54,580
not discovering it three months in when finance asks why headquarters numbers look stale

605
00:42:54,580 --> 00:42:59,860
build the integration around that reality instead of hoping it turns out faster than documented

606
00:42:59,860 --> 00:43:04,420
phase three decide the elimination and consolidation logic on purpose

607
00:43:04,420 --> 00:43:08,900
don't assume fnose native module will absorb intercompany transactions coming from an outside BC

608
00:43:08,900 --> 00:43:13,620
system because it won't reach across that boundary automatically this has to be built tested and

609
00:43:13,620 --> 00:43:19,380
owned by someone specific not inherited as a side effect of turning fn o on phase four run the

610
00:43:19,380 --> 00:43:24,260
actual BC to fnome migration as its own project its own budget its own timeline its own testing

611
00:43:24,260 --> 00:43:29,540
window separate from the integration work in phase two and the consolidation logic in phase three

612
00:43:29,540 --> 00:43:32,980
bundling this into the integration project is how timelines quietly triple

613
00:43:33,620 --> 00:43:38,580
one more piece belongs inside phase four and it's the one organization's cut first when a deadline

614
00:43:38,580 --> 00:43:44,100
gets tight a parallel run period two to four weeks minimum both systems live at once producing numbers

615
00:43:44,100 --> 00:43:49,300
side by side not a demo a real operating window where finance checks that fnose output matches

616
00:43:49,300 --> 00:43:53,940
what BC would have produced transaction by transaction before anyone commits to a full cutover

617
00:43:53,940 --> 00:43:58,260
skip this and the discrepancies don't disappear they just wait until after cut over when they're

618
00:43:58,260 --> 00:44:03,380
harder to trace and more expensive to fix here's what ties all four phases together every phase that

619
00:44:03,380 --> 00:44:08,180
gets skipped early doesn't vanish from the project it shows up later dressed up as a fire nobody

620
00:44:08,180 --> 00:44:12,340
budgeted for costing more to put out than it would have cost to handle properly the first time the

621
00:44:12,340 --> 00:44:16,100
order isn't a suggestion it's the only sequence where each phase actually protects the one that

622
00:44:16,100 --> 00:44:20,980
comes after it common mistakes that make this worse five mistakes show up again and again in

623
00:44:20,980 --> 00:44:25,140
these projects and none of them are exotic they're the ordinary kind the kind that feel reasonable

624
00:44:25,140 --> 00:44:29,940
in the moment and only look like mistakes once the invoice for them arrives mistake one waiting

625
00:44:29,940 --> 00:44:34,340
until the acquisition closes to think about integration the deal team runs due diligence on

626
00:44:34,340 --> 00:44:39,700
financials on legal exposure on customer contracts and nobody in that room asks what ERP the target

627
00:44:39,700 --> 00:44:44,340
runs or what it would take to connect it integration planning starts the week after signing instead of

628
00:44:44,340 --> 00:44:49,140
the month before which means the company loses exactly the window when it had the most leverage to

629
00:44:49,140 --> 00:44:54,260
shape the deal terms around what the systems could actually support mistake two assuming it can

630
00:44:54,260 --> 00:44:59,300
quietly handle this in the background no budget line no headcount allocated just an expectation

631
00:44:59,300 --> 00:45:03,460
that the existing team will absorb a multi-system integration on top of everything else they're

632
00:45:03,460 --> 00:45:08,420
already doing i doesn't say no because it rarely gets asked in a way that invites a no the work gets

633
00:45:08,420 --> 00:45:13,780
done badly slowly or both and nobody upstream understands why until the numbers start looking wrong

634
00:45:13,780 --> 00:45:18,980
mistake three treating the finance and operations move as a technical project instead of a business

635
00:45:18,980 --> 00:45:23,780
process redesign as covered earlier the hard part isn't the data it's the process and a project

636
00:45:23,780 --> 00:45:28,340
plan that only staffs developers and database people misses the actual work entirely procurement

637
00:45:28,340 --> 00:45:32,500
manufacturing sales all of them need seats at that table from the start not a training session

638
00:45:32,500 --> 00:45:37,460
bolted on at the end mistake four keeping every scrap of historical data instead of defining a

639
00:45:37,460 --> 00:45:41,300
retention window upfront this one feels safe in the moment like nobody ever got in trouble for

640
00:45:41,300 --> 00:45:46,420
keeping too much but undefined retention means undefined scope an undefined scope is how a project

641
00:45:46,420 --> 00:45:54,020
that should take 12 months quietly becomes 18 one unreviewed data set at a time mistake five skipping

642
00:45:54,020 --> 00:45:59,140
the parallel run period to save time the deadlines tight the boards asking questions and running two

643
00:45:59,140 --> 00:46:03,940
systems side by side for a month feels like a delay nobody can afford so it gets cut and the

644
00:46:03,940 --> 00:46:08,820
discrepancies that period would have caught don't disappear they just wait until after cut over when

645
00:46:08,820 --> 00:46:14,020
tracing them back to a root cause takes three times as long and costs three times as much look at

646
00:46:14,020 --> 00:46:18,500
these five side by side and one thing stands out they don't share a technical cause they share a

647
00:46:18,500 --> 00:46:23,380
psychological one every single mistake comes from treating this wall as a surprise something nobody

648
00:46:23,380 --> 00:46:28,420
could have seen coming instead of what it actually is a known feature of how these two systems relate

649
00:46:28,420 --> 00:46:33,300
to each other the organizations that avoid these mistakes aren't smarter they just stopped being

650
00:46:33,300 --> 00:46:38,180
surprised what this means for the next five years zoom out from any single company story and the

651
00:46:38,180 --> 00:46:42,020
patent sits underneath all of it this isn't going away if anything it's getting more common because

652
00:46:42,020 --> 00:46:46,820
more companies are growing through acquisition then through slow organic expansion and every acquisition

653
00:46:46,820 --> 00:46:52,340
carries a chance of landing two ERPs in the same org chart private equity roll-up activity is

654
00:46:52,340 --> 00:46:57,060
the clearest driver here the playbook is well known at this point by a handful of small companies in

655
00:46:57,060 --> 00:47:01,220
the same industry combine them sell the combined entity at a multiple higher than any single piece

656
00:47:01,220 --> 00:47:05,460
would have fetched alone each of those small companies almost certainly already runs an ERP

657
00:47:05,460 --> 00:47:09,140
and a meaningful share of them run business central because BC is exactly the kind of system

658
00:47:09,140 --> 00:47:13,780
a company that size chooses that means the collision covered throughout this episode isn't a rare

659
00:47:13,780 --> 00:47:18,340
edge case some unlucky IT director stumbles into it's a structural feature of how a large and

660
00:47:18,340 --> 00:47:23,060
growing share of the activity actually works Microsoft's roadmap doesn't close this gap either and

661
00:47:23,060 --> 00:47:27,700
it's worth being precise about why the investment keeps flowing into data verse into co-pilot into

662
00:47:27,700 --> 00:47:31,380
connective tissue that makes moving data between products smoother than it used to be that

663
00:47:31,380 --> 00:47:35,140
investment is real and it helps but connective tissue isn't the same thing as a bridge between

664
00:47:35,140 --> 00:47:39,700
two different architectures a better sync job doesn't change the fact that business central

665
00:47:39,700 --> 00:47:44,740
and finance and operations were built on different assumptions about scale different posting logic

666
00:47:44,740 --> 00:47:49,060
different data models Microsoft is making the seems less painful to manage Microsoft isn't

667
00:47:49,060 --> 00:47:53,060
erasing the scene so the organizations that come out ahead of this pattern aren't the ones

668
00:47:53,060 --> 00:47:56,980
avoiding business central waiting for some future version of the ecosystem where the wall

669
00:47:56,980 --> 00:48:01,860
doesn't exist that version isn't coming the ones who come out ahead are the ones who architect

670
00:48:01,860 --> 00:48:06,740
for consolidation before they needed who treat the chart of accounts the master data the documentation

671
00:48:06,740 --> 00:48:11,460
habits covered earlier as groundwork laid on a normal Tuesday not as a crisis response after the

672
00:48:11,460 --> 00:48:16,180
deal already closed the wall isn't disappearing that's the plain fact underneath everything in this

673
00:48:16,180 --> 00:48:21,220
episode the only variable left for any given company is whether they see it coming from a distance

674
00:48:21,220 --> 00:48:25,620
with time to plan a phased approach or whether they hit it at full speed in the middle of a deal

675
00:48:25,620 --> 00:48:30,580
with a board already asking questions nobody has good answers to yet key transformation and

676
00:48:30,580 --> 00:48:35,380
implementation challenge here's the shift this whole episode has been building toward stated as

677
00:48:35,380 --> 00:48:39,780
plainly as it can be stated moving from business central to finance and operations isn't an

678
00:48:39,780 --> 00:48:44,740
upgrade it's a decision to rebuild on a different foundation and the earlier that decision gets made

679
00:48:44,740 --> 00:48:48,660
on purpose the cheaper every part of it gets that's not an abstract principle it turns into a

680
00:48:48,660 --> 00:48:53,220
specific task one you can start this quarter instead of filing away as some day work if you're

681
00:48:53,220 --> 00:48:58,020
running business central today and any acquisition is even a possibility over the next two years even

682
00:48:58,020 --> 00:49:02,820
a vague one even one that's just a rumor in the industry you're in audit your chart of accounts

683
00:49:02,820 --> 00:49:07,140
and your customizations now before the deal happens not after the term sheet is signed and someone

684
00:49:07,140 --> 00:49:11,140
in finance is suddenly building spreadsheets under deadline pressure that audit doesn't need to be

685
00:49:11,140 --> 00:49:15,540
exhaustive to be useful it needs to exist know what's documented and what isn't know which

686
00:49:15,540 --> 00:49:20,580
customization solver real problem and which ones nobody remembers the reason for know whether your

687
00:49:20,580 --> 00:49:25,220
chart of accounts could survive a second entity showing up next to it without a rebuild none of

688
00:49:25,220 --> 00:49:29,620
that requires predicting the future it just requires refusing to be surprised by it here's the

689
00:49:29,620 --> 00:49:34,820
stakes worth naming one final time because it's the whole point of everything covered so far the

690
00:49:34,820 --> 00:49:38,740
companies that get hurt in this pattern aren't the ones that stayed on business central staying on

691
00:49:38,740 --> 00:49:43,300
BC was never the mistake the companies that get hurt are the ones that assumed a bridge existed

692
00:49:43,300 --> 00:49:48,420
between BC and F&O some upgrade path Microsoft would eventually build and found out otherwise

693
00:49:48,420 --> 00:49:52,820
in the middle of a deal with a board waiting on numbers and no time left to plan properly

694
00:49:52,820 --> 00:49:57,700
that's where we'll leave it for this episode if this saved you from budgeting a migration

695
00:49:57,700 --> 00:50:03,140
that was actually a full rebuild in disguise that's worth a review on the m365fm podcast

696
00:50:03,140 --> 00:50:07,940
say so directly it helps other people find this before their mid deal and scrambling for answers

697
00:50:07,940 --> 00:50:11,460
if you want to keep this conversation going connect with me my co-peters on linkedin

698
00:50:11,460 --> 00:50:15,620
and their most days and i genuinely like to hear which Microsoft ecosystem assumption

699
00:50:15,620 --> 00:50:19,860
deserves the same kind of structural breakdown next there's no shortage of them one last thing

700
00:50:19,860 --> 00:50:24,260
stated planions that have wrapped in false comfort the wall between BC and F&O isn't going

701
00:50:24,260 --> 00:50:26,740
anywhere so plan for it before it plans for you