Evolving from a GP Administrator to Becoming a BC Administrator
Evolution brings change. If you are on Dynamics GP and looking to migrate to Business Central, but are curious about the system administration of the application, this is the place where I share my experience and explain what the transition means from a GP system admin perspective.
Having been a GP application and database administrator for over 400 companies, I want to just put this out there right now - I love everything about the access to SQL Server. I know what server it is on, how old it is, who has access, how much RAM it has, what the used and free disk space is on each of the drives, what applications and antivirus is installed, and have alerts that ping me via email when adverse conditions exist (e.g. failed backup or low space). I know the network and can tackle any access issue on any machine anywhere.
I’ve now been a BC application and database administrator since Business Central was released. The job is very different. You should know your role as a GP system admin changes dramatically with Business Central.
Naturally, with BC being a SAAS, cloud-based application, there is no workstation installation. Anywhere. No Dynamics.set file to synchronize, no service pack code to locate, and no risk of corrupting the reports and forms.
User administration for Business Central is performed much differently than for GP. As a GP Admin, you are responsible for logging into the application as the ‘sa’ user and creating a SQL-specific user account that will be used. That user needs to be assigned company access, and then security roles for each company. For BC, user accounts start off as Microsoft accounts, and licenses are assigned to named users in Azure Admin console. The license allocation triggers the billing for each per-user account based on the level selected ($70 for basic functionality or $110 per month for advanced manufacturing and more.) Once the account has a BC license assigned the BC Admin can log into BC and sync users with Office 365 which pulls in new users and updates existing ones whose licenses have been deactivated. Once the user is added to BC the admin can dial in the company and user-specific permissions as required, much like GP.
Disaster Recovery for Business Central was a key concern I had making the transition from GP. After all, with GP I had complete control of the nightly backups and hourly transaction logs in SQL. This enabled me the confidence, demonstrated on more than one occasion, to restore a customer’s environment to a ‘point-in-time,’ just before the unrecoverable problem or data corruption occurred. A must-have in ERP system administration.
In Business Central, we maintain this disaster recovery capability; in fact it is automatic. You can restore a production environment to a point-in-time just like with GP, but the tools for managing that process are different. Since BC is all in the cloud, you need to have the appropriate administrative rights to log into the BC Admin portal to execute on a point-in-time database restore. From my experience the recovery process was easy, worked well, and I now know how this works having practiced it a few times to demonstrate for customers as part of an audit. Thankfully, Microsoft keeps the backups in the cloud for you for a 30-day window of time, but hopefully you know you are in a disaster recovery situation within minutes, not hours or days, or you may be in real trouble.
With Business Central, having the ability to quickly copy a production company over to a test company has changed dramatically vs. the way we do it in SQL Server with Dynamics GP. Within the BC production environment it is really simple to copy a database to a company, and use that for testing something out. Be aware, however, that during the period of time while the new TEST company is being created, the PROD company is frozen, and users cannot log into or process anything in that company until the new TEST company has been successfully created. The lesson here is to plan on doing this off-hours or at lunchtime to minimize disruption to the end users.
Test environments are different than a test company in BC. In the GP world, we ask if there is a separate SQL server, with a different GP launch file that only points to the test server. This is/was a luxury for some, but an absolute necessity to many users who have complex and interconnected GP ERP systems. Bottom line is I would bet more than 80% of all GP customers don’t have a dedicated DEV or TEST environment running on separate hardware. That means in some ways they are winging it, and ingesting updates to SQL and GP only when manually initiated. In the BC world, we are granted 3 DEV environments, so thankfully Microsoft has made managing this part really easy and it has also leveled the playing field for all of its ERP subscribers by providing this.
So let’s discuss BC ERP updates, customizations and ISV solutions, because that’s what this is really all about to help bridge the gap from being a GP system admin to a BC system admin.
When you customize Business Central you are doing so in the Extensions layer of the application. This means Microsoft provides the base code, and then extensions enable features and perform functionality beyond the core BC code. These are essentially managed in two places - first and foremost the Extensions Management window in BC, followed by the BC Admin console. They can be deployed from AppSource, through importing, and through deployment as a per-tenant-extension (PTE). Extensions are sometimes free, sometimes require a monthly or annual subscription, or can be created and deployed by a skilled BC developer. Extensions are created with AL code, with the Visual Studio Code application, and deployed to first a sandbox environment for testing and QA, and then ultimately to a production environment for everyday use. Sometimes extensions and customizations can conflict with upcoming releases of Dynamics Business Central, and the tenant administrator is notified accordingly. The affected extension will need to be corrected and redeployed to the production environment by the assigned cutoff date in order to continue working as expected, otherwise the extension will automatically be rendered disabled and not perform as expected.
Space utilization is always a consideration for an ERP admin, and this can be managed in the BC Admin console. Total available space is tricky to calculate, but it starts with a footprint starting with 80 GB across the one Production and all three of your Sandbox environments. Keep in mind that each copy of a production company takes up 2x the space really needed, so delete test companies as soon as they are no longer needed, but especially before creating a new sandbox. I recommend putting the date of the copy in the company name so you can see in 9 months it is really old, and can probably be deleted, before copying the environment into a new sandbox. The multiplier effect is tricky, so stay on top of it. There are additional space multipliers that pertain to extra space allotments that kick in at the per-user level, but I am not covering that here.
BC also doesn’t have network and file-level concerns like we had with accessing the Reports.dic in a GP Shared folder which is arguably the weakest link in all of Dynamics GP. The reports for Business Central are all either SQL-based RDL files or Word Template-like documents that can be formatted and then propagate data much like they do with Dynamics GP. The layouts and designs are stored in the BC database instead of at the file-level like GP. This makes them much less susceptible to corruption or accidental deletion. They are also secured through user permissions, instead of a domain user group and a network shared folder.
As a GP admin, I always look forward to new features and functionality with each release. The same is true for BC nowadays. The release cadence for BC feels faster than GP, with wave one coming in April and wave 2 updates coming in October each year. There are periodic minor updates, and new features could theoretically become available at any point in time. The Release Planner is a good place to bookmark for monitoring the inevitable updates coming your way.
Hundreds - even thousands of extensions are available on AppSource for Business Central. These are comparable to GP ISV solutions. The problem is its the wild west out there - some you can try or use for free. Some are available via subscription of varying amounts. Some start for free then suddenly cost money. My advice here is that you get what you pay for. What support do you expect, or recourse do you have with a free app? Some of the best extensions cost some real bucks every month because they perform some amazing feats of automation or functionality which increases accuracy and decreases reliance on humans to perform certain critical tasks.
I have to admit, the paradigm shift from being a GP sys admin to becoming a BC sys admin has been dramatic. Revolutionary in fact. First of all I don’t have to open a VPN and log into a server, then launch GP and SQL Management studio in order to be remotely effective. The new world order requires me to simply log into BC or the Admin console in a browser.
I’m grateful should this experience or these insights be helpful to you on your journey…until next post!