Budgeting a Business Central Implementation

A budget is a set of decisions, not a single figure

SCSB is regularly asked what a Dynamics 365 Business Central implementation costs in Malaysia before anyone has described the business it has to run. That question cannot be answered honestly at that point, and a figure produced anyway tends to be wrong in ways that surface during testing or cutover.

A budget becomes useful when it describes the decisions behind the number. Public list prices, an indicative range or another organisation’s project cost cannot establish the cost for a particular Malaysian organisation. Licence tier, user mix, localisation, extensions, data condition, integrations, testing and internal change effort all alter the scope, and each is a decision somebody has to make and own.

Microsoft publishes current Business Central plan and pricing information for Malaysia. Check it and the applicable commercial terms at the time of decision, because availability, pricing, currency treatment and licence conditions vary by location, agreement and date. Everything below is the scope around that licence line.

Settle the licence shape first

Microsoft lists three Business Central subscription types: Essentials, covering finance, sales and operations; Premium, which adds service management and manufacturing; and Team Members, described as limited access to read data, approve workflows, and create or update selected information.

Two documented behaviours change the arithmetic more than most first drafts allow for.

• The experience setting applies to the company, not to the individual. Microsoft documents that the Experience field on the Company Information page controls which features are available to all users in the company, and that users with an Essentials licence cannot sign in to a company that uses the Premium experience. A single manufacturing or service-management requirement can therefore pull an entire company onto Premium licensing rather than a handful of named users.
• Not every person with a login needs a full licence. Mapping who genuinely originates transactions, against who only approves or reads, is worth doing properly. Doing it late usually means the user count is already fixed in a quotation.

Record the assumed user split as a written assumption with a named owner. It is the line most likely to move between a first quotation and a signed scope.

Malaysian localisation and statutory workflow are scoped work

This is the item most often missing from a first budget, and Microsoft documents it plainly.

Microsoft’s country and regional availability documentation lists Malaysia as available with the localisation provided by a partner, on the international (W1) base application, rather than as a Microsoft-delivered local version. Microsoft states that in countries and regions where it does not deliver a localisation, partners build localisations as apps published on the Microsoft commercial marketplace, built on top of the W1 version.

Three consequences follow for the budget and the risk register.

• Malaysia-specific functionality arrives as one or more marketplace apps, each with its own publisher, licence, release cadence and support route. Identify the exact apps and publishers before signing, and establish who answers when one fails mid-period.
• Those apps are a dependency at every major update. If a localisation app is not ready for a new major version, that is a scheduling problem for the finance calendar, not a background technical detail.
• Requirements assumed to be standard product behaviour may be app-dependent. Test them against the intended app set, not a demonstration environment running a different country configuration.

The same documentation notes that the environment’s country setting determines both the localisation and the Microsoft Azure geography the environment database is deployed to, mapping Malaysia to the Asia Pacific geography. Where data location matters to a customer contract, a lender, a group IT policy or the organisation’s position under the Personal Data Protection Act 2010, settle it at the environment-creation decision rather than after go-live, and take anything carrying legal weight to the organisation’s own adviser. A deployment setting is a fact about the system, not a compliance conclusion.

Statutory workflow belongs in the same part of the budget. Business Central includes an e-documents framework for creating, sending and receiving electronic sales and purchase documents, with configurable services and optional service integration to an access point. Microsoft documents that using e-documents requires configuration, and that e-documents are not created automatically when that configuration is wrong.

That is a statement about product capability. It is not a determination of what any taxpayer must submit, when, or in what form. Where SST or MyInvois e-Invoice workflow support is required, treat it as a defined requirement with named acceptance tests, and take the obligation itself from current guidance issued by the responsible Malaysian authority — the Royal Malaysian Customs Department for SST, and LHDN for e-Invoice. Confirm the organisation’s own position with its tax adviser. A licence, implementation or supplier statement does not decide it.

Break the budget into decision areas

A working estimate normally distinguishes the following, each with an owner and an acceptance test rather than only a number.

• Product licensing: the tier, the user mix by role, add-on apps and renewal assumptions.
• Discovery and design: processes in scope, decision owners, requirements, and the criteria by which the design is accepted.
• Configuration and extensions: standard configuration, approved extension work, permission sets, and integration design.
• Data work: cleansing, mapping, migration, reconciliation and how much history moves.
• Testing and cutover: test cycles, user acceptance, issue resolution, conversion runs and go-live controls.
• Change activity: training, communications, procedure updates, and working time from internal process owners who still have their normal jobs.
• Ongoing operation: support model, update management, security administration and future change requests.

The last two are most often absent from a first budget, and most often responsible for a project feeling more expensive than it was quoted.

Data migration is where estimates move most

Microsoft provides built-in cloud migration tooling, but its documented scope is narrower than “the data will be moved across”. The supported migration paths cover Business Central on-premises — version 25 and later directly, versions 15 to 24 after an on-premises upgrade, and version 14 through a separate reimplementation route that moves only essential data such as master data, opening balances and setup — plus Dynamics NAV, Dynamics GP 2015 and later, and Dynamics SL 2015 and later, each with its own supported path, plus any other SQL source through a custom migration. The source database must run on SQL Server 2016 or later at compatibility level 130 or higher.

If the current system is not a supported source, the built-in path does not apply and migration becomes bespoke work. That is a discovery question, not a third-month surprise.

Separately from tooling, four decisions carry most of the cost:

1. How much transactional history moves, and how much stays in the outgoing system as a read-only archive. Migrating everything is the most expensive default, and often unnecessary.
2. Who cleanses master data, and against what deadline. This is internal effort, and it is usually underestimated.
3. Who reconciles opening balances, and who signs them off as correct.
4. What “correct” means for each migrated area, written as a test a named person can pass or fail.

Environments and entity structure carry their own cost

Microsoft documents that Essentials and Premium subscriptions give each customer one production environment and three sandbox environments free of extra charge. Additional production environments are purchased through a CSP partner, and Microsoft states that each additional production environment comes with three additional sandbox environments and 4 GB of additional tenant-wide database capacity. Microsoft’s documented operational limits record a maximum of 300 companies in one environment and a total environment database size of 3 TB.

For a group with several Malaysian entities, or entities in more than one country, this is a structural decision with a recurring cost. Decide early whether entities share an environment, and record why. Consolidation, intercompany processing, reporting scope and localisation all depend on that answer, and changing it after go-live costs materially more than choosing it deliberately at the start.

Budget for the update cycle, not just the go-live

Business Central online is updated on a published schedule, and the effort of staying current belongs in the operating budget rather than being discovered during the first year.

Microsoft’s update cycle documentation records two major update cycles a year, released every April and October, with minor updates in every month except those two. Administrators set a maintenance window per environment and can reschedule a major update within a five-month update period. A one-month grace period follows, and then an enforced update period, during which Microsoft documents that extensions causing an update to fail might be automatically uninstalled so that the update succeeds. Data belonging to an uninstalled extension is not deleted, but the functionality is unavailable until a compatible version is installed.

In budget terms that means:

• Two regression-test passes a year against the organisation’s own critical scenarios, with named owners and allocated working time. Microsoft’s guidance is to test critical business scenarios before production environments are updated.
• Active maintenance of every marketplace app and per-tenant extension relied on, including the Malaysian localisation apps.
• A sandbox pass on a copy of production data before each major version, and a decision on who signs it off.

A quotation that ends at go-live has not described any of this. Ask for it explicitly, in writing.

Ask every provider for assumptions, exclusions and acceptance criteria

Two quotations can look similar while describing different work. Ask each provider to state, in writing:

• the assumed entity, company and user counts, and the licence mix;
• the modules and processes in scope, and those explicitly excluded;
• the localisation apps assumed, their publishers, and who supports them;
• how much data history is included, and who cleanses and reconciles it;
• the integrations included, and what happens if a third-party system changes;
• who performs testing, who accepts it, and what evidence records acceptance;
• what triggers a change request, and how it is priced;
• the post-go-live support period, and what follows it.

It is also reasonable to conclude that a full implementation is not currently proportionate. An organisation with simple processes, clean data and no integration requirements may be better served by a narrower scope, a phased start, or by staying on its current system until a specific constraint justifies the change. A budget that reaches that conclusion has still done its job.

Next step

Where an organisation has selected Dynamics 365 Business Central and can describe its entities, users, data condition, integrations and reporting requirements, SCSB’s Business Central implementation service can be discussed. A reliable estimate depends on those facts; without them, any figure is a guess.

Dynamics 365 Business Central, Microsoft and Microsoft Azure are trademarks of the Microsoft group of companies.

This article is general information about implementation planning. It is not legal, tax or accounting advice and does not determine any organisation’s obligations. Product capabilities, licensing terms and regulatory requirements change; confirm the current position with the relevant authority, with Microsoft, and with the organisation’s own advisers before committing expenditure.