Dynamics Corner
About Dynamics Corner Podcast "Unraveling the World of Microsoft Dynamics 365 and Beyond" Welcome to the Dynamics Corner Podcast, where we explore the fascinating world of Microsoft Dynamics 365 Business Central and related technologies. Co-hosted by industry veterans Kris Ruyeras and Brad Prendergast, this engaging podcast keeps you updated on the latest trends, innovations, and best practices in the Microsoft Dynamics 365 ecosystem. We dive deep into various topics in each episode, including Microsoft Dynamics 365 Business Central, Power Platform, Azure, and more. Our conversations aim to provide valuable insights, practical tips, and expert advice to help users of businesses of all sizes unlock their full potential through the power of technology. The podcast features in-depth discussions, interviews with thought leaders, real-world case studies, and helpful tips and tricks, providing a unique blend of perspectives and experiences. Join us on this exciting journey as we uncover the secrets to digital transformation, operational efficiency, and seamless system integration with Microsoft Dynamics 365 and beyond. Whether you're a business owner, IT professional, consultant, or just curious about the Microsoft Dynamics 365 world, the Dynamics Corner Podcast is the perfect platform to stay informed and inspired.
Dynamics Corner
Episode 424: Business Central: Insights from Real-World Implementations
In this episode of Dynamics Corner, join hosts Kris and Brad as they delve into the intricacies of implementing Business Central, featuring insights from Jesse, Rama, and Pablo, who share their experiences transitioning from NAV 2013 to Business Central 2024. Discover the challenges, strategies, and successes of managing a large-scale upgrade across multiple companies, and learn valuable lessons for your ERP journey.
#MSDyn365BC #BusinessCentral #BC #DynamicsCorner
Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/
Welcome everyone to another episode of Dynamics Corner. What does it take to implement Business Central? I'm your co-host, Chris.
Speaker 2:And this is Brad. This episode was recorded on May 1st 2025. Chris, chris, chris, what does it take for a BC implementation? Migration, upgrade, re-implementation, whatever you want to call it? With us today, we had the opportunity to speak with an end user that recently had gone through a migration from 2013 to a recent version of Business Central. With us today, we had the opportunity to speak with Jesse Rama and Pablo. Hello, hello, oh, look at that, look at that. How are you doing?
Speaker 1:good, yeah, I got my sweater too, but I'm not wearing it right now.
Speaker 4:See that, see that, jesse this is uh this is uh, we're gonna get you one, even though you're not an mvp, oh wow, but you have the fancy hat I like the hat. You like my hat I'm not wearing it. I just wanted to mess with you you're the host now. That would have been a first I was gonna come in with my boston accent and start being like, hey, what's going on?
Speaker 2:That wasn't a Boston accent Get out of the box after this that's a Southern accent.
Speaker 4:Yeah, I do have a Southern accent. I'm sorry.
Speaker 2:It's okay, y'all should see me.
Speaker 4:I am tucked away in the corner of my son's bedroom because there is construction going on downstairs in my house. And then I got all the way up here and my neighbors are cutting their trees. So yeah, this is my life.
Speaker 2:It always happens to me. Oftentimes, if you know, you can see me scrambling because we do a recording. It is it's always inevitable that somebody comes and bangs on the door. Somebody just the lawn team decides to come and cut the lawn or something, yeah, and they stop, so they, they stop hopefully they're done.
Speaker 1:They're doing construction in your house.
Speaker 4:Whatever they're doing they are remodeling my shower and they're putting in a closet for me, a closet, a closet system for me, so like it's just a bunch of people in and out. It was supposed to be done by now. Are you treating this?
Speaker 1:like a bc implementation where you know staying in budget and, oh, I'm in budget the construction people are over budget.
Speaker 4:They ruined some stuff and I'm like I'm not paying for that.
Speaker 2:You did it, oh yeah well, speaking of the bc implementations, we do appreciate you taking time to speak with us this afternoon because you, as a user of Navision or Dynamics Nav re-implementation, which we hope to speak about how that process went, what you did as an organization to ensure that it went smoothly, some of the pitfalls or challenges that you uncovered that you didn't expect, maybe give some insights to someone who may be listening. But before we do that, would you mind telling us a little bit about yourself? Jessie, we'll start with you.
Speaker 4:Hi. Yes, I'm Jessie. I am the senior business central NAV support manager. So I've been with Forum for 10 years this year, but I've been in the NAV business central world for about 17 years. So other than that, you know, I do all this volunteer fun stuff for the Dynamics Communities Business Central Board and I help run the local user group meetings. And not to do a shout out, but we are having our very first local chapter meeting in Houston in June Yep, since 2019. So it's all planned in books. So just wanted to throw that out there because I'm proud of it.
Speaker 2:Excellent Congratulations which date in June.
Speaker 4:June 24th, from 10 am to 2 pm at the Microsoft Center.
Speaker 2:Excellent, excellent, hope everybody attends Me too. Look forward to seeing what the agenda is, pablo.
Speaker 5:Yes, so, pablo Hernandez, I've been with Forum for 17 years with the BC support and BC security admin team.
Speaker 2:Excellent, excellent, rama, would you mind introducing yourself to us as well?
Speaker 3:Sure, my name is Rama Satyapeda. I've been doing nav, like the development, for almost like 20 years and I enjoy doing support also. But I don't get to do a lot here in Forum, but in my previous companies I do support and develop. My background is a developer, but you know, I like doing both uh, development and support. And it's been nine years before.
Speaker 4:So in a few months I mean next year I'll be it'll be 10 years for me too excellent and just so you know rama, this is recorded, so I'm gonna go uh sign five support tickets to you right after this that's okay okay that is what you, what you have give me support work but I'm like
Speaker 3:the level 3 support.
Speaker 1:I support the support team basically when everything really goes to hell, give it to Rama. Is that how it works?
Speaker 4:oh yeah when we're done everything we can and we're stuck and we're lost. We're like Rama, we need you to look at this. We have one other internal developer as well who's not on this call that we do the same thing to. We're like you're going to have to walk through this with us, yep.
Speaker 2:Nothing ever goes to hell. So it sounds like all of you have been working there for quite some time. Working there for quite some time, and what were you using before you moved to Business Central? Nav13, nav2013r2. Nav2013r2, just shortly after you went from the roll-tailed client to out there, and with that, what made you wait to go to the business central?
Speaker 4:upgrade, or why hadn't you upgraded to the previous versions of? Nav through the years from 2013 through 2018 so technically, the first, very first project this was in the works before I even started um at this company, they were getting everybody off of nav 5 and nav NAV 2009 onto NAV 2013. So when I started, we were still moving people to that, so that just took a very long time.
Speaker 3:We were doing what one company at a time when I started yeah, yeah, we did one company or a couple companies, but there's a lot of companies in NAV 5 and NAV 2009.
Speaker 2:how many companies do you have?
Speaker 3:75 around 70 75 companies, 75 yeah, yeah, I think we tried to merge a few and now we are down to like around 50 or 55.
Speaker 1:Yeah, well, that makes sense why it took a long time.
Speaker 2:Huh, yes, I could see that 50 companies and within those 50 companies, some of them just financial companies.
Speaker 4:Yes, so what features?
Speaker 2:within the application are you using within these companies?
Speaker 4:So I would probably say about half would be finance companies.
Speaker 3:Rama, that we just do general budget, post-general budget, yeah, 25 operational companies, 25, 30 operational companies, and then the remaining 25 are finance companies.
Speaker 4:Yeah, finance companies, and the finance companies very like small. We just do like they just post a general journal entry in there once a quarter or once a month. Nothing major happens in those. The rest of them we do like sales service. Jump in anytime, pablo, and tell me more Warehouse, advanced warehousing in some we do basic with bins, in some we have inventory count. Time collection module. Thank you, what am I missing? I feel like there's more Scan guns.
Speaker 2:We're kind of across the board.
Speaker 4:Manufacturing, hello manufacturing. I was waiting for that.
Speaker 2:So it sounds like you used a lot of the application and, with having an internal development team, you had also some of your own modifications, or you might have a significant amount of modifications, and when you migrated to Business Central kind of let's walk through the process of what you had done to plan or prepare for it Did you go to Business Central online or you were using Business Central on-premises?
Speaker 4:On-prem. We got outvoted on that one.
Speaker 2:You could have voted on that one.
Speaker 4:We tried, we tried so hard and they were like nope, we're staying on-prem and we're like all right.
Speaker 2:A lot of implementations have their reasons for going on-premises and others go online. I'm happy to see that, as time is progressing, some of those limitations or reasons why I don't want to use the word limitation, but some of the reasons why some prevented or wanted to go, some of those reasons that prevented some from going online and staying on-premises, are being relaxed a little, which is nice. So there are some slight differences.
Speaker 1:Yeah, I do want to go through that process with what your process went Deciding to move to Business Central. Brad, and I want to understand. You have deciding to move to business central. You know Brad wants that, brad and I wants to understand. Like such a, you have a lot of entities, right? It's certainly a big implementation. You use all different modules within business central, I'm sure, using different add-ons. It's a lot of coordination that's happening. So, as you decide to move to business central, was it a natural path to go to Business Central or did you also look at other ERPs as well? And when you decided, what did that committee look like, right? So you know, was there change management, project management, all that stuff being put in place?
Speaker 4:So, yes, we did. Actually, there was another ERP that was being considered at the time, um, when I me and my boss actually at the time we presented business central because, uh, we have what? Seven business central employees, right, that are just specifically for support five or support to our developers and that's what we do and that's our job for this company. So we presented it. As you know, business central was the best route one because we're already on nav. So the functionality is basically the same, right, you're going to enter a sales order, the same way You're going to everything like that, right, we also told them it would be a lot more money to switch ERPs, which we all we did the work on that, obviously it would be, and they wanted to upgrade, they did not want to re-implement.
Speaker 4:So you can't upgrade to SAP or another GP, whatever you pick in the thing. You can only upgrade to BC, right, so that was kind of our walkthrough for that. And then, once we got the approval, we originally were going to jump to NAV 2018 first, and we did in the background, but we didn't do it for the, you know, for the users. Um, so we decided we could get to BC 14. Um, so we did that instead. So we did the work to get there. We started with two companies, right guys?
Speaker 5:Yes.
Speaker 4:Um, yes, we started with two of our companies. They were kind of our like test companies who do, who use a lot of the models in the system, also have the best users for us. We have a lot of power, we have power users in every ledger, so they have, like, the best users. So for that it was like we wanted them because we knew we would get the best testing out of them. Right, I have you know. So we picked them. That project for them was six months. For us it was a year, behind the scenes, right when Rama, you can probably talk more about those jumps in the background on the technical side.
Speaker 3:Yeah, I mean more. Like you know, we converted the code from. I mean, we removed most of the code from Microsoft objects and separated it in preparation for the future upgrades and then we have a script which actually copies the companies. As you know, we started with two companies and we cannot go to a different database. We started with one database with two companies and then, as we upgrade the other two or three, we just used to copy those companies into the initial upgraded company. So, yeah, the first step from NAP 13 to BC 14 took a little longer because we have all these companies and we want to make sure everything is included for all of the companies. I think it took around like a year and a half, right? Yeah, I think we started yeah a little over.
Speaker 4:We were already doing the refactoring piece right to prepare for it, and I think that was like a year and a half, two years, something like that, yeah.
Speaker 1:But then once yeah, go ahead. Yep, but then once yeah, go ahead. So you worked on all of this in the back end, using you know two to three companies as your sort of a pilot. You know you've identified your subject matter experts when you've decided to move forward and then slowly added all these other companies along the way and then kind of repeated the process to, you know, towards the other companies as well. So it created a foundation, it sounds like, for you and then kind of repeated the process slowly with the rest.
Speaker 4:Correct.
Speaker 4:Yeah, so the first one we did we took we were giving a timeline of six months. So we have three PMs that helped with this. Right, we have three internal PMs, our team and then the SMEs. So you know, we we follow the regular phases of a project. We kicked off, we went through um like we demoed it for everyone because we did and this is going to probably surprise y'all, but we did go to the web client to be seen on BC 14, um, which was not a fun thing at first but it was beneficial.
Speaker 4:When we took the next jump, um to get them used to it. Uh, so we, we did it six months. They kind of like helped us stabilize all the major issues that came out of that um as we were doing testing for that. And then when we started doing the rest of the groups, which I think we did what three more groups? It was like six at a time. After that, those we did in four months at a time each round. Yeah, so it was pretty fast-tracked after the first round was kind of complete.
Speaker 2:You have some of the testing. So, going from 2013 to BC-14, you chose to upgrade versus re-implement, which means that you brought all of your historical information over and had that as part of the upgrade. The other point that you mentioned is you had a lot of modifications within the system and you decided to refactor that. Well, you had to refactor the code in essence to accommodate the future development and the way that the extension structure is for coding. How did you determine which modifications to keep? Did you go through a phase of reviewing the functionality of Business Central versus the modifications you have put in place to see which modifications you bring forward? Because I know personally that's always been a challenge with organizations upgrading or even migrating or re-implementing Business Central from an earlier version. They have a lot of modifications they made, they spent a lot on those modifications in both time and money, and sometimes, before they even touch it, they want to bring all that stuff forward. What process did you go through to evaluate which modifications to bring?
Speaker 3:forward versus the functionalities within Business Central. So basically what we did was we have an external Excel actually Google Docs actually where we used to have customization specified for each company separately, like if a company requested it, we used to keep track of which company requested it and how many companies are going to use this. So we had something in place to identify how many customizations we have. I mean, may not be 100%, it's basically when I started in forum. From then we kept track of it. It's from 2016. So when we started with the first two companies, we would go and see how many customizations are requested by this company, and I know how many are being used by other companies. So we would go to the power users and ask them are you really using these customizations anymore? They would say yes, no, and that would let us know okay, how much should we keep it?
Speaker 3:And the second step is when we are merging the code with Microsoft. Most of the times you know it's similar, you know the field convention or whatever. So then when we're merging, actually we had an external company help us. So they would let us know okay, we have this code, do you want to still keep it or no? You know, of course I had me and my other developer. We have to analyze and make sure, okay, we need it or not. So it's a little bit of manual work also. And then going to the business and we had. It's not easy but we had something in place that would help us to identify all these customizations, which ones to keep, which ones to remove.
Speaker 1:You made a great point on what other end users or people that want to decide to move to Business Central to really have in place. You had mentioned that you've documented the development or customizations you've had in Nav and then you quickly identified okay, are they being used? So you're doing an internal discovery and I appreciate you mentioning that because you know a lot of times some of these you know businesses that's coming from Nav go into Business Central. They don't have those documented. So you putting some work behind that, some effort. It really prepared you to identify okay, do we need to bring this technical debt or not?
Speaker 3:Yep.
Speaker 1:Right. So I think that's a fantastic way to get yourself on a good foundation.
Speaker 3:Yep. That really helped us to identify what to keep and what to eliminate from the customization. And also at the end of the day.
Speaker 5:I mean, it's about standardization as well. So you want to standardize across companies and you want to make sure, okay, if there is a customization that could help another company, then they can utilize that, we can keep it. So that was another big thing.
Speaker 4:Yeah, and just to add to that too, a part of this round of upgrades that we did to get to BC 14, we used to have like 20 different posted sales invoices. Now we have one per country. Like, we standardize a lot of those documents so when they ask for updates we don't have to update 20 documents, we can just update the one or things like that. So we did a lot of document standardization on top of that. But, and reports some of the reports we had like two or three versions of. We were able to standardize those as well. But I mean data-wise you can't really standardize that once it's in there. So a lot of it, some of it like unit of measure, has been a big issue for us. In some locations it's EA and others it's each things like that. But we did get to standardize what we could while we were doing this.
Speaker 2:No, it's excellent and it is a great exercise, as Chris had pointed. You can do an inventory of what you have and what you need and only bring forward what you need as well, which is a big help.
Speaker 4:It's worth.
Speaker 2:In my opinion, it's worth the effort and the time that you may spend, as you're going through an upgrade or a re-implementation, to really take a step back in inventory of what you have, and through this process did you have to do any data you mentioned the unit of measure Are there?
Speaker 4:any other data cleansing or data standardization considerations that you had to make? We had to okay. So was that on the BC 14 jump we had to remap item categories? Is that when it changed to the hierarchy?
Speaker 5:Yes.
Speaker 4:So we had to get that mapping redone and reloaded. What else was there? Was there another one that I can think of?
Speaker 2:No but what we did was yeah, it was a main one.
Speaker 3:It was a big deal, all the open documents you know, since if you don't go to the next version it'll be there. So what we did was we cleaned up a lot of open documents you know, like logs and everything, before upgrading. We didn't want to do all the data, so we did quite a few cleanup in every jump we did we could. Yeah.
Speaker 4:And we did have some fields that ended up being that we customized, that ended up being standard fields, that we mapped during the upgrade process and got rid of our custom field. I can't think of any off the top of my head.
Speaker 5:External document number reference number. There you go.
Speaker 4:Thank you, I knew you would remember, paula, this is me. We started this project in what 2022, 2022. We started this project so, and we got to 2024, wave two uh in march march, was it march, we went live with that.
Speaker 2:Yeah, so we just finished.
Speaker 4:We just got up to date in march and just finished.
Speaker 2:So yeah, well it's it. It does take some up to date in March and just finished no-transcript well, we had to jump in between there, didn't we? You went to 18 or no.
Speaker 4:We didn't go from 14 to 23 and then to no NAB 2013.
Speaker 3:He's talking about NAB 2013 to BC.
Speaker 4:14. Bc. 14 to 23.
Speaker 3:Bc 23 to BC 25. 5 to the 8.
Speaker 4:Whatever you pick it, I don't know why he did that.
Speaker 1:Everybody still has the same issue with version numbers right, he's so confusing. I have that issue daily.
Speaker 2:You know, it's 25, it's 24, it's 23, it's 2025, wave, one which is 26, which is it's I I don't know they should.
Speaker 4:Yeah, yeah, it's very confusing, but yeah. So we we took our time. Getting to BC 14, right Rama, we did it ledger per ledger. We getting to BC 14, right Rama, we did it ledger per ledger. We put them on the web client because we knew we were jumping again pretty fast, so we wanted them to be used to that view rather than that classic view, that Windows view. So when we jumped to 23, everybody went at one time. We didn't take them per company, so that was a fun job.
Speaker 2:So organizationally, you went from 2013 to BC 14. They were functioning on BC-14. Then you did another migration to 2024, wave 2. Or to 23 Wave.
Speaker 3:No 24, Wave 2.
Speaker 4:We had to jump in between there Between 14 and 24, wave 2. We went live last August with it.
Speaker 3:Yeah, that is BC-2023. 2030, yeah, so you went live last August with it. Yeah, that is BC 2023.
Speaker 2:So you went from 23 then to 24. You can see why we're confused.
Speaker 3:We don't know where we are.
Speaker 2:Okay, so so, and you did that jump to for one. It sounds like for them to be familiar with the application. Yeah, was there? Another consideration Is that when you converted the extensions from the code from CAL to AL as well?
Speaker 4:Yes, from the BC14. Yeah, BC14 to 23 is when we converted the code.
Speaker 2:Okay, yeah. So your first step was to review your modifications, determine what you need to bring forward. You made and brought those forward to BC 14 and Cal. You then went through and did some data sanitization. I'll call it to the best you could to clean it up a little bit. Then you made at that point you had to now go to 23, which was, with 14 being the last version where you could use cal right. 23 is now where your full extensions. What was the process like for migrating the code to 23?
Speaker 3:um, I mean as to al I should say right yeah, yeah, when, like as I mentioned, you know, even in the NAP 13, when we did the refactoring in the back end, we had the NAP 2018 database where we moved all the code to functions and that helped our external team to move from BC14-Cal to AL. So I mean, it was we already gave them outlines, you know, defined everything, so they just had to move the code from cal to al for us converted that's a that's a great strategy because you went to bc14.
Speaker 1:Um, it kept the back end in terms of cal, uh, but you did that so that you have a better user adoption, to get them very comfortable using the web client on bc14. So when, when you did that so that you have a better user adoption, to get them very comfortable using the web client on BC 14. So, when you did the CAL to AL in 2023, it didn't really affect so much with the users because it's like hey, I'm already in BC 14. I'm comfortable with the layout and the look. The user adoption 23 is like oh, we're just with no more features. Yeah, right, yeah, that's exactly what it was.
Speaker 4:That was the exact plan, yeah exactly, yeah, pc 14 web client.
Speaker 3:Of course, as you know, that was like there's some limitations in it, and they were excited when we kept saying that, okay, all these things will be fixed in 23, next version. So and for them they really they didn't have any difference when they upgraded 23, except that they have more features available. So that's fine. And the backend side? They don't need to know what's happening on the backend side and we are already preparing on from 13 itself to 14. And then when we had to move to the AL on the 23, so it was not that bad as we thought, like all the code conversion was good.
Speaker 1:Was it fun when they went to BC 14? You know, bc 14 web client was, you know, a fun one, right? And then so you had to convince them like, hey, it's going to get better guys.
Speaker 4:It's going to get better. The main issue with BC 14 is the personalization it sucks Like it's terrible and that was like our biggest complaint. They were jumping in and out of role centers trying to change things Like you know it's. They couldn't. They just couldn't do the things that you can do in nap 13 when you personalize Right, and that's like a big deal to have your own view of how you look at the system. So we were like just hang on. When we get to 23, it gets better. Please hang on.
Speaker 4:But, like every group we rolled out, we would get ticket after ticket after ticket. I hate, I can't personalize. I hate it, I hate it, I hate it. That was our biggest issue, right.
Speaker 5:The biggest one, oh yeah.
Speaker 4:So a couple of our ledgers. It depended on the phase right, so we started in 2022 and I think all the way till what August of last year. So we had, you know, people were coming in each phase but they had to live in BC 14. Yes.
Speaker 5:Yes, not happy with this either.
Speaker 4:And they were like but we kept giving them the hope, we're like, we're almost there. We're almost there. You know when we went into testing for BC 23,. You could see people were happier. Just with the personalization, just with bookmarking, they're like oh, I get my bookmarks Just being able to bookmark. Yeah, it was funny.
Speaker 1:That made me laugh, brad. Remember hope isn't a strategy, but it sounded like this was a strategy and it worked.
Speaker 4:Yeah, it worked, it works. I mean yeah, but we had to keep going. But if we would have stopped, I think they would have killed us at some point.
Speaker 2:No, it does, because the product matured over the years as well. I mean, it was a big jump even back then. I'm it so that they could get everybody to it and then start hearing some of the things that they know that they needed to invest, to add it sounds like.
Speaker 2:I don't know if that was the case, but it's almost like like what you're saying just bring everybody there, get everybody to a certain stable point, then now take into consideration what people are missing and what people are asking for and then invest and add to that for them to have it. So, and it's an interesting journey that you have. So now you went from 14 to 2024. Wave two is where you ended up, yes, and now you just finished the switch. Has the dust settled yet?
Speaker 4:yeah, actually it has. Um pablo actually ran that project so you could probably speak to it. The best pablo, I mean.
Speaker 5:You were in the, you're in the thick of it yeah, I mean we had less than 20 issues really reported. Most of them were due to some of the release included pages that we had custom. So our custom pages were replaced with now the standard Business Central, like Service Archive, for example. We had a custom for that, so that had to get replaced. So there were some permissions that were also required for that. So most of the issues that we had were related to permissions to new objects and let's see, maybe our extensions that's just about it or add-ons, something like that. Wow, that's excellent.
Speaker 1:So when you went from 2013 all the way up to BC24, what was the ratio like in terms of changing business processes versus customization? Clearly, there's some things that you didn't bring over. You know, was there a lot of that business process changes?
Speaker 4:I don't think there was anything like major. We did have to leave behind. Um, we had our own document attachment process and NAV 13 that did not upgrade, but we moved everybody to just regular attachments and and people seemed to love that more. I don't think we had, except it didn't exist on the service side, but we built that for them. But I can't think of any other major process change that happened.
Speaker 5:I think the other one was templates. Item templates.
Speaker 5:Oh item templates yeah, mm-hmm, yeah, so they have the. You know, in NAV 13 and BC 14, they had their item templates that they could use and set up what's mandatory, etc. But now you have in BC 25, you have your. I'm not even sure what the difference. I think it's configuration templates, maybe, and now in BC it's item templates. So some of those fields that were included in NAV 13 and BC 14 are no longer available on the standard item templates that they had that they have to use now in BC 25. So we're still battling that one.
Speaker 2:Yeah, yes we are still battling that one in the UK. Well, that sounds like a good one. So, looking back at the implementation and how you went through the planning, so you did the demonstrations to validate the product that you were moving to. You viewed your customizations, you did some data sanitization, you did an initial jump to increase user adoption and, I'm going to assume, to also test the functionality as you migrated from Cal, which was the wild wild West, to an organized version of Cal. Then you converted your AL code and then you migrated up to the version of business central that you're running now. That's a lot.
Speaker 4:It doesn't sound like a lot and people don't realize it's a lot. It sounds like it's so easy. That's it. You summed it up. But hey, look that last jump from like 23 to whatever we're calling this version we're on right now 25. Yeah, that was like a breeze. We just called that a monthly release for us.
Speaker 5:I don't yeah that one was clean. That one was clean, that one was super clean.
Speaker 4:So our goal moving forward because we're on prem, so our goal moving forward is to always be, I think what two jumps behind Rama? Maybe be I think what two jumps behind rama, maybe one jump. If we can, if it looks good, um, that way we can. You know, we can work out kinks and stuff like all those kinks get worked out before we make that next jump.
Speaker 2:Um, so, but you, know, the more current you stay, the easier it gets the easier it gets, yeah it was well because just you don't have as radical changes as because they are evolving. The application, add in features toin functionality, the changing the data structure, which is, again, it's a normal part of the evolution of software as business needs. But if you can stay current with it, that's the advantage of the online version. You stay current with it.
Speaker 2:All the time you don't have to go through a three-year implementation for each step. Hopefully you can do it a little bit easier. So, as far as the movement of the data, how did you move the data as you upgrade it? Did you use the standard tools for that? Did you have to get?
Speaker 3:Most of them are standard tools, but we have quite a few custom fields, so we had to include our custom fields also. Uh yeah, we, we didn't spend a whole lot. It's most of them the standard uh tools. Only we used standard Microsoft tools.
Speaker 2:I'm very happy to hear that, because I know others. I've known others that tried to do other external ways and sometimes they paid for it right because the, the, the way it is of course done in extensions is all the custom fields are in a different table.
Speaker 3:They give us EXT as an appending to the standard tables, which is a good thing. So I mean we use the standard Microsoft tools to convert all the data.
Speaker 2:Yeah, that's excellent. I'm happy to hear that, and if you have a lot of data to move, it must have taken some time to run? How much? If you can say, I mean any of this stuff. If you cannot say it, I understand as well.
Speaker 4:I think one ledger was what 48 hours or something.
Speaker 3:Overall the whole database is. Our database is 900 GB.
Speaker 2:So it's 900 gigabyte Gig, right yeah. So it's 900 gigabyte, Right yeah. And it took you how long to move it. It must have been challenging to do individual companies.
Speaker 4:Right, not to BC14. It wasn't, was it? That one was not that bad.
Speaker 3:No, no, the latest upgrade. We did all these 800, 900. Gb. It took like 15 hours, wow, that's good.
Speaker 2:That's not that bad at all.
Speaker 3:There's a few things we did after that, which is not related to the upgrade, but we included it because it's the cleanup process and all. But in general, the Microsoft upgrade process didn't take like 15, not more than 20 hours definitely.
Speaker 2:There you go yeah.
Speaker 1:We had to do it over the weekend, used the standard tools?
Speaker 4:Yes, for sure do all the weekend Used standard tools. Yes, yeah, sure, yeah.
Speaker 2:No, the standard tools were into it. So, looking back at this, if you could summarize, you know from each of you what are some things that you thought went really really well and because of what, for whatever reason. From preparation or planning, you know what went really well because of that and from preparation or planning, you know what went really well because of that. And then maybe, now that the dust is settling as we discussed, what would you have done differently or what have you uncovered as you went through that process? So somebody else who may be going through the similar journey, taking pieces every implementation is different but they may have not thought of something that maybe that you realize you should have or may have done differently, not thought of something that maybe that you realize you should have or may have done differently.
Speaker 4:I'll say one of the things that I think we did really well is we have a very strong group of power users in every ledger that we depend on for testing. So, like my team will internally test, right but we don't know everyday functionality of what goes on in every one of those ledgers. So when we identified them before we kicked in every one of those ledgers. So when we we identified them before we kicked off every one of these projects and we asked them to break our system, literally we were like please break it, do what you can to break it. We want to know, and I think that was like the biggest thing that we did. That was helpful for us during this upgrade, cause we caught a lot of stuff in the first round. I think that would have been so major show-stopping if we had four or five going at a time, like four or five ledgers going at one time.
Speaker 2:Just to jump into that, you had SMEs that worked with you on the testing. Going through this process, often with the implications of challenges, is how much time do you give someone to do testing? How do you manage the testing to make sure that they're actually testing? Did you have any tools in place to help with the testing? And then what about what some people say the day job? Because as you're going through this implementation, you may have these power users and they do more than just test.
Speaker 4:They do just more than I'm assuming know see how things are working. They do have a day-to-day work for it.
Speaker 2:But how did you manage that to allow them to have time to test, and how did you track the testing and come up with use case scenarios for them to test? What was that process like?
Speaker 4:I'll give that one to Pablo, because he just did the last round of it, so he's probably got it fresh in his mind. I'll give that one to Pablo, because he just did the last round of it, so he's probably got it fresh in his mind?
Speaker 5:Yeah, so definitely. I mean, we took the release notes and those release notes. We divided those up. We were seeing what was going to impact us, what wasn't Like some of the AI stuff that's in there, the co-pilot things, I mean we're on-prem, so that's not going to affect us. So we kind of took those out of the equation and we just worked on what was going to impact all of our ledgers and then we assigned those to our SMEs on our support team and those SMEs tested internally and then we created the test scripts if needed for our end users to actually test. We set a deadline for them to test and then, once they passed it, then we were good to go. We were good to to release that with the BC 25.
Speaker 4:Yeah, and that one was for the 25. For the rest of them, we actually have super scenarios that we established a long time ago, um, that we make all of our and we use TFS um for testing. So we make them go in and sign off on them in there. Um, for you know, they're very generic test scripts, basically like the basics to creating a sales order, you know, shipping a sales order, invoicing, whatever. Um, if they have any other fields that they require, things like that, we ask them to make sure they test them on their own.
Speaker 4:Um, for all of these updates that we've done, we have sessions.
Speaker 4:We have two-hour sessions with the power users where we make them sign off on the test scripts and do the actual testing, and then we do separate sessions for training for everybody else who wants to join. Everything gets recorded so if someone can't join they can watch it later. We do have certain power users who do go above and beyond for us and they would take, like, if they're in like sales, they would actually take five or 10 orders they entered in their live environment during the day and they'd spend an hour at the end of the day entering these types of orders in to the test environment just to have real live kind of scenarios. So we're kind of lucky with those. We't require those. We only have to have a sign off on a test script. But we do ask for those kinds of things so we do have. Like I said when I say our power users are the best, like we have some really good power users out there that want to make sure they function great when we're live. So it helps us out.
Speaker 1:That's fantastic to hear like you know you giving that and I know Brad and I had plenty of conversations with others in the community where you have to give an opportunity for them to be able to test, and it sounds like you have that planned out where you're giving them two hours, you know, whatever day that is, and just all they do is like, hey, you're allowed to do this, you're encouraged to test, you're allowed to do this, you're encouraged to test, you're encouraged to break the system and get comfortable with it and not reprimand them for you know, hey, you're not meeting your day-to-day task. You know what I mean. And then do it at the same time. Help us implement this thing. So you have one of those like I hate to say, rare, it is, it is.
Speaker 4:It took us a long time to get these power users on board too. I think it's gotten better with every jump we've done. I think they've learned, but like it took us a while. But yeah, we really do have great power users that do that we also. I mean that environment was it's it's, it's a testing environment. I think it was there for what? Two, three months for them to test in during the whole process. What cause? We were doing sessions and we were like you don't have to wait for us, you can log in right now and start your testing, we're just going to have the session anyways, kind of thing. Um, we had early morning 2 AM sessions and then repeated them again at noon, just cause we're, you know, international and the major thing too. Sorry, ron, I'm just going to say this.
Speaker 4:The major thing too is we make them test with whatever permissions they have in production today. So a lot of people just give up and want to test functionality and set all their users up as supers, and then they go live and then they have no permissions to do anything. So we do test permissions along with that whole process as well.
Speaker 2:That is beautiful because I know of so many implementations that the first day they start, everyone gets frustrated because they can't do anything. And it's because, as you had mentioned, they didn't want to inhibit testing, because they didn't want users to get frustrated with permissions. But then they just sort of pushed that down the road, because now, when they're going live and they're supposed to work, it seems like nothing's working because they can't do anything.
Speaker 2:It's because the permissions. So it's great that you tested with that and you flushed that as well too, and now, since you're up into the latest version, you can incorporate the new love of my life page scripting. That can maybe help you with some of these testings.
Speaker 4:I hope so. Yeah, it's on my list. Yeah, so we actually have one location that we acquired Was it last November, I think they're. They're a business central online and he uses the page scripting our support guy over there and he loves it. We have to be able to record the results somewhere when someone runs the test, because we get audited and we have to show test results. Yeah, so that's the only thing we haven't really figured out yet, but it is on our list. I know, pablo, haven't? You dove into it a little bit.
Speaker 5:Yes, a little bit, a little bit yes. As soon as we had that update on there and that release note, I went and tried it out and, yeah, it was great it's wonderful Replay will track the test results for you.
Speaker 2:Oh, that's good yeah.
Speaker 4:My guy at Veriperm. Well, at the other ledger of Veriperm, yeah, he says he just takes screenshots and I'm like I'm not saving screenshots yeah, pablo, take a look at Replay.
Speaker 2:You can automate some of those tests and it will track the results for you.
Speaker 4:Okay, Thank you.
Speaker 2:It will give you a lot with it. It does give you videos, it gives you the results, it gives you everything, so you'll be able to see, if you'd like to see the actual test, that are going with it too. So it sounded like the testing was something that you thought you did really well. What about? And we?
Speaker 3:always say one more thing to you, and every time we upgrade not only creating new orders we make them test the orders existing before upgrade. You know partial up orders because if something got upgraded we don't know, so if you create a new it might work. So that's something we make sure they test new orders and old orders, and partial you know invoice or shipments or whatever for the old and new orders.
Speaker 4:So yes, that's an invoicing and, honestly, that is a result of our tax engine. When we did the last update, we had to actually write a script to revalidate all our orders for tax because they weren't validated. Yeah, we learned that one. On group one of the BC-14 jump they weren't validated.
Speaker 1:Yeah, we learned that one on group one of the BC 14 jump. No, you need those taxes.
Speaker 4:Need taxes yeah.
Speaker 2:So so do you have anything that you think went really well from your perspective, other than testing?
Speaker 5:I would say yeah, I mean I would say for for, from a permission standpoint, testing with the user's permissions internally. That's always helpful as well to make sure that you can, you know, get those error message before you hand it over to the user, so you can test with Super just to make sure that everything works, everything functions correctly. But then also turn around and give your take a user, a power user, copy their permissions, give it to your user. That way you can test with their permissions and you can catch everything beforehand. That's also really helpful. And let's see, I like Jesse said, I mean our power users are great, so that's definitely a plus in our SMEs, on our team.
Speaker 2:It's excellent, excellent. It all comes down to the users to make the implementation easier. Also, the users sometimes don't realize they're making it easier for themselves, and by getting them in there, it sounds like they were able to have some ownership of it as well. So I think it's a little bit easier if they feel that they have a good part or part of the implementation process, versus it being forced down their throat, to say it bluntly which is nice, ramas, anything that you look back, that you thought went really well, that you planned for.
Speaker 3:I mean, overall, everything's fine. For me being on the technical team, the way we started doing the code conversion, you know, and then now it's ongoing. Actually we still find some issues and we'll just make sure that we follow the standards, like basically Microsoft standards, you know. I know we cannot customize any of the standard objects now, so we just try to keep it as separate as it is, so more easy for the next upgrade. So the timeline the reason why I'm saying is every time we've been upgrading from 13 to PC, 14 to 23 to 25, the timeline went down every time we're doing it.
Speaker 3:So that really made a good thing, we are separating everything from Microsoft Objects, so, which means, when we are upgrading it, we just take it out, upgrade Microsoft and then plug. It means, when we are upgrading it, we just take it out, upgrade Microsoft and then plug it in and that's it. So we are doing really great on that. Excellent, excellent.
Speaker 1:I do like your cadence to do one to two versions behind right.
Speaker 1:Yeah yeah, because a lot of times where people move to on-prem business center, they kind of just leave it alone as if they'll never upgrade again and it is an internal conversation or internal decision. Okay, how far back do you want to be behind? Because then you go back to that same old ways of nav where you stay in nav 2013 right for years to come, versus with business central, with the way you guys have set up, you're setting it up every two versions behind at most and so you're always upgrading. So that's fantastic it is.
Speaker 2:It is you get the latest updates as well. So if there are things that aren't working properly or need to work slightly different, you get those.
Speaker 2:So you can alleviate some frustration and again, as we were talking about it, goes much quicker in retrospect, looking back. What is something or some things? If you have that you look back that you wish you had done differently, or you wish you had planned differently, sort of something that you had learned that maybe didn't go the way that you wish you had done differently, or you wish you had planned differently, sort of something that you had learned that maybe didn't go the way that you wanted and you wish you had either known about or planned differently.
Speaker 4:Oh, rama, you should tell them about the server patches. Remember the server patches ran during the upgrade? Yeah, right, and rolled it back. Yeah, that's of course an internal schedule. Now, during the upgrade, yeah, yeah, and rolled it back.
Speaker 3:Yeah, yeah, yeah. That's, of course, an internal schedule now. I mean, it happened for one first time and then from then onwards we just make sure we keep track of any patching not done during the you know go live, because we lost a day. Luckily that it was for BC23, I think we gave a buffer, a lot of buffers, so that's why we didn't really, even though we lost a day of work because of the patching for the servers, but still we made it. But that's something, yeah, we made it in the deadline.
Speaker 3:The deadline was made because we planned ahead.
Speaker 4:We planned for it. Yeah, we gave ourselves a day.
Speaker 3:We gave ourselves a day, a day extra. Of course, pablo said when we started this upgrade he went through the Microsoft release notes, but I think we 100% don't want to go with whatever they're saying because they missed some of them. When we are doing the code conversion, then we have to do QA and see what else is involved in it, because there's some things Microsoft might think it's not a big deal. I think there's a field which they made it a mandatory during the code but it's not even there in the release notes. But it is a process for our side it affected, but it didn't make a huge difference. Process for our site it affected, but it didn't make a huge difference.
Speaker 3:We had to work after the release upgrade but we overlooked it because we thought, okay, well, they didn't do anything. So for the next version not only the release nodes we have decided to go through the. We'll just do a QA, like Microsoft objects, and see what is that they removed or what is that they added and we can analyze is it going to affect us or not. So that's one of the things for us. For the technical side, we have to do it next time.
Speaker 2:Yeah, it's good. I've heard stories like that before, so you're not alone where they had server reboots or other maintenance plans scheduled and it threw things off quite a bit. So you're not alone in that aspect. Are there any other things that you can think of that you wish you would have planned differently for or handled differently to? Anybody that may be, going through the process or was it just perfect? No other thing? No, we're not perfect, you know, I will say we had.
Speaker 4:we had some add-ons that we kind of struggled with. I know our tax engine. For the first jump I think we just assumed everything would update but we had to actually reload a lot of stuff with our tax engine, revalidate, run those scripts to revalidate all the open orders Just stuff we weren't expecting, that we didn't catch during testing. I remember that for the tax piece I know Pablo for was it the TCM we lost some historical data that you had to go and manually load.
Speaker 5:Yes for some posted time cards, things like that yeah.
Speaker 4:So I mean all fixable things just weren't caught in the front end because nobody thought let me go look at my historical posted time card lines, you know, or you know everybody just assumed once you plugged in your tax engine all you had to do is click statistics again and it would be fine. But not everybody does that. So just little things like that does that. So just little things like that, other than that, we're perfect.
Speaker 2:It sounds like you went well I mean you spent some time to plan it.
Speaker 2:You had the users testing and fortunately you have the right individuals on your team to help push it through and guide you through it. Not all implementations have to be problematic, and nor, in this case, are implement are all implementations problematic, but it just goes to show that a little bit of planning and proper procedure can make it easier and you don't have to rush through it. I know it's not easy. Sometimes you can get those users in there, but if it's sometimes just training issues versus having systemic or data issues, it makes a little bit easier. But I'm happy to hear that you had a pleasant journey with the application, which is great.
Speaker 3:Yeah, our project planning timeline is. I think it's perfect. You know we all agree with the timeline. Sometimes they crunch it, but normally yeah. But you know, in general the planning team, like project manager planning is actually good yeah.
Speaker 1:They're heavily involved as well, sorry to interrupt. Yeah.
Speaker 5:No no that's good.
Speaker 1:I was about to ask about the managing of the project. Clearly, you know the three of you are in the trenches and testing and making sure you know users are testing, but at the same time you have somebody has to coordinate all of that, right? So I'm sure you're working with all the different internal departments, but then you also have, potentially, your partners and your ISVs that you work with. I mean, those all still have to be coordinated. So and Jessie, you had mentioned you have four project managers. Did I hear that right? We have three. Well, we have four project managers. Did I hear that right?
Speaker 4:We have three. Well, we have four, but three were on the project, but one of them is the manager of the project managers. I don't know how to the project manager manager. Pmo.
Speaker 3:PMO.
Speaker 4:And he helps out too as much as he can, but the three were actually the ones planning it together. We did, I think, not for 14. Did we bring the two other?
Speaker 2:ones. Remember we had two consultants come in.
Speaker 3:That was 23.
Speaker 4:Yeah, they came in and helped during the 23 one because it was a bigger jump. It was like all the ledgers were jumping at one time it was more. But for the BC 14 jump we had the three and we really laid out the foundation for that and just fast tracked it for the rest of it.
Speaker 1:Were there internal PMs or were there. Okay, so with you, I mean works.
Speaker 4:Yeah, three internal PMs for the BC 14 jump and then we had three internal and two external for the 23 jump. Yeah, just because we were taking more ledgers at once. The only regret I have with the fast tracking of the timeline when we went to, like, from 14 to 23, like in there or some of the BC 14 updates afterwards, is we tried to merge testing and training into one session and I think it caused a lot more confusion at some areas into one session and I think it caused a lot more confusion at some areas. I don't think I'll do that again. I think we'll just keep it separate moving forward. Do you remember that, pablo?
Speaker 5:Yes, definitely yeah, we had to change it up in the middle.
Speaker 4:We tried something new and it, you know it, I think everybody was confused on who had to sign off on the test scripts was the main thing. But yeah, we were like no, just this person, it's fine you know, but yeah it gets a little confusing in there.
Speaker 1:Yeah, it definitely is. I mean, especially what worked before. Yeah, you tried something new. It didn't work. You know you iterate fast. Now, going back to the ISV comment I made earlier, was there any ISVs or add-ons that you had where it didn't exist in Business Central? Did you come across any of those and if so, what was your process like in replacing them? Or did you even replace it and just change the business process? Was there any of that happening?
Speaker 4:No, I think everything updated. The attachment is the one they didn't upgrade.
Speaker 3:We used the standard Microsoft functionality, which process-wise is not different, but it's just different Microsoft we are using, and I think, easy security they didn't upgrade but the standard Microsoft security is good, so we had these two not working in the Business Central, but Microsoft options are already there, so we didn't have to really replace it.
Speaker 5:Did the rental fall into that Rental module? We?
Speaker 4:removed the rental module because it wasn't being used. During the update we stripped that out and one of the shipping add-ons that we had sold those ledgers and they were the only ledgers that used it. So we stripped the shipping that shipping add-on that we had out as well.
Speaker 1:Got it. So there wasn't major ISVs or add-ons where like hey, they're not going to Business Central, so there was a major change. I mean you mentioned Easy Security, but then you have a replacement for that you know out-of-the-box functionality.
Speaker 4:Yeah, Okay, Everything else. Updated Everything else. Yeah, had an extension we could use.
Speaker 1:So you had the perfect storm.
Speaker 4:I guess they would say, right, like, just everything, just… I mean we still had to customize some of those extensions to make them work for us. With our processes we have a very, very customized inventory count process. So that one actually when we jumped to 23, wasn't ready yet. It took a little bit longer. Um, so people were having to like, do me, we have, like we have a process in place where we schedule random counts. So we have like it's a job runs and it just creates a count for us and then they go print it and they do counts. That wasn't working. So they were having to manually run their accounts every week to do the randoms, things like that. Just little things that weren't ready yet. But, like I said, that inventory account module that we use, we customized it a lot to just work with our policy that we have for accounting inventory. So, yeah, sure, other than that, I mean everything else I think was pretty straightforward. Quality took a little bit longer. Pablo.
Speaker 5:Yes, yeah, quality was new because it moved from what it was to separate, so it was kind of a package before quality and time collection, but then they separated that, so that was a new thing.
Speaker 1:Got it. So, with with all of this successes, you have certainly a lot of planning that you've done. You know everything went up pretty smoothly. You know, are you? Are any of you doing any speaking sessions then to talk about how you should do a business, central implementation or upgrade?
Speaker 4:No, this is great. Haven't you met me by now? You know how much I hate speaking Like oh Lord.
Speaker 2:That's a good point.
Speaker 4:I did volunteer Pablo to join the New to BC panel for Summit. So me and Pablo will be on that panel at summit new to bcs with
Speaker 1:david volunteer.
Speaker 4:Still pablo, that was that was voluntold so I had one of my employees do it with me last year, but she's not going this year. Um.
Speaker 2:So I was like, well, pablo, you can do it, you'll be good I'm looking forward to that, seeing that session you'll probably have a session at the same time, so you know, probably not the new to bc they usually do first right, the first step the first timers meeting is that's me, steve chinsky and kim dollfield and that's on day one.
Speaker 4:That one's like a fast chat one. This one's that panel one, the ask the experts panels. We do for every track we usually do for every track. I added ours because I wanted ours in there, because ours was very successful last year. We had a lot of questions.
Speaker 2:A lot of um people who were moving over from gp were in there asking us a bunch of questions I think you'll have a lot of questions this year based on what I see and what I know that there are. Thankfully the product is sort of exploding.
Speaker 4:Yeah, that's why David Laster's in there, because he's very, very knowledgeable on that migration.
Speaker 2:That's good to have someone in there.
Speaker 1:We'll take this recording. You set your structure of your agenda. Then you submit your session to how to implement Business Central in a 55 company. That's actually impressive.
Speaker 5:Brad summed it up earlier, so we have the notes already. Yeah, there you go. We'll get to the transcript and you can go through the process and tell your tales and go from there.
Speaker 2:Well, jesse Pablo Rama, thank you very much for taking the time to speak with us today and share your story. It's nice to hear you know a nice implementation story of Business Central and what it takes to go through implementation, and it's nice to hear that they're not all bad and some of them are very easy and a lot of them are very easy as well I regards me here. So we look forward to seeing you in Orlando in October. Hopefully I can go to your new to BC session as well, and we look forward to talking with you soon, thank you.
Speaker 5:Thank you, thank you, perfect Thanks for having us.
Speaker 1:Thank you, bye.
Speaker 2:Thank you, chris, for your time for another episode of In the Dynamics Corner Chair, and thank you to our guests for participating.
Speaker 1:Thank you, brad, guests, for participating. Thank you, brad, for your time. It is a wonderful episode of Dynamics Corner Chair. I would also like to thank our guests for joining us. Thank you for all of our listeners tuning in as well. You can find Brad at developerlifecom, that is D-V-L-P-R-L-I-F-E dot com, and you can interact with them via Twitter D-V-L-P-R-L-I-F-E. You can also find me at Mattalinoio, m-a-t-a-l-i-n-o dot I-O, and my Twitter handle is Mattalino16. And you can see those links down below in the show notes. Again, thank you everyone. Thank you and take care.
