Keeping SAP Business One healthy after go-live: who supports what

Go-live is not the end of an ERP project. For a finance director running a growing UK business, the quality of SAP Business One support over the following years decides whether the system keeps pace with the company or slowly becomes the thing everyone works around. This page explains what SAP itself provides, what your integrator should provide, and how to write a sensible support and maintenance contract.

SAP Business One support: two layers, two responsibilities

SAP Business One is sold and implemented through a channel of partners. SAP reports a network of 850 partners, with more than 500 industry and country extensions, which is why the support model is split in two.

• SAP is responsible for the product: new versions, fixes, security corrections and statutory updates, plus its own support channel for product defects.
• Your partner is responsible for your installation: how it is configured, which add-ons and integrations sit around it, and how your users are helped day to day.

Most disputes about support come from this boundary. A user cannot post a purchase invoice, and nobody is sure whether it is a product defect, a configuration choice or a custom report. A good contract settles that question before it arises.

What SAP covers

The maintenance page states that SAP offers round-the-clock support (24 hours a day, seven days a week) for system standstill incidents. Beyond that, the maintenance agreement gives you access to product updates. Every customer with a valid maintenance contract receives version upgrades at no extra licence charge, which matters when you are modelling the long-term budget (see SAP Business One pricing).

SAP also sets the lifecycle rules:

• standard maintenance is guaranteed for at least five years per version family, counted from general availability of the major release;
• extended maintenance is not offered, and once a new version family arrives, maintenance on the previous one stops;
• SAP provides no fixes or security patches for outdated feature packages, support packages, patches or hotfixes.

In other words, staying supported means staying reasonably current. The current family, version 10.0, is shown as being in standard maintenance until 31 December 2028, with the usual caveat that dates can change. Versions 8.8, 8.81, 8.82, 9.0, 9.1, 9.2 and 9.3 have left standard maintenance. SAP's page only notes that version 11 will follow version 10, without a date, so do not build your plan around an assumed release.

What your partner covers

The partner's scope is whatever your contract says it is, which is exactly why the contract matters. A typical managed arrangement includes:

1. Application support: logging, diagnosing and resolving incidents raised by your users.
2. Corrective maintenance: fixing defects in your configuration, reports, workflows and custom developments.
3. Evolutions: small changes such as a new approval rule, a modified document layout or an extra field, ideally priced separately from incident handling.
4. Upgrade management: testing and applying new feature packages and support packages, and planning the move to a new version family.
5. Monitoring and housekeeping: backups, database health, licence checks and user administration, especially if the partner also hosts the system.

Where the partner has built extensions, the support of that code is the partner's job, not SAP's. Read the customisation page before signing so you know which items will fall into that category.

Maintenance, support and TMA: using the right words

Quotes use the vocabulary loosely, so pin down the meaning of each term.

If you read "TMA SAP Business One" on a proposal, treat it as a managed service contract and ask what is inside the fixed fee and what is billed on request.

Understanding SAP's update model

Since version 10.0 in April 2020, SAP has delivered innovation continuously through cumulative feature packages. These bring new functions, fixes, security corrections and statutory updates, and interfaces remain stable between the major version and its feature packages. SAP distinguishes several types of delivery:

• Feature packages for new capabilities;
• Support packages for corrections, security and statutory updates;
• Cumulative patches for SAP Business One Cloud and associated products;
• Hotfixes, which are only temporary solutions outside the normal cycle.

For your support contract, this has three consequences. First, ask how often the partner applies packages and whether a test copy of your database is part of the routine. Second, ask how statutory changes are handled: HMRC-facing features, such as those that matter for Making Tax Digital, need to be tested before an update reaches live ledgers. Third, remember that direct version upgrades are supported only between consecutive versions, so a company that has skipped a generation needs several steps. That is slower and costlier than keeping up, and it is the most common reason for an audit or project rescue. The versions and editions page sets out the differences in more detail.

The support access question

On-premise installations include a support user account, created at installation, so that partner staff can log in without consuming a licence. It is locked by default and every use is logged. SAP also describes a control: the connection is refused if the Remote Support Platform has not completed a transmission in the previous seven days.

This is useful to know when you review your contract:

• who unlocks the account and when it is locked again;
• who reads the logs;
• whether any remote tool is installed on your servers, and who controls it.

The licence guide also lets the manager user log in from two separate Windows sessions without locking the first, so that scheduled tasks such as reporting or imports can run, or so a consultant can connect without a licence. It is not meant for double productive use, so do not let it become a shortcut for two people sharing one login.

Service levels worth asking for

Do not accept a contract that says only "support during office hours". Ask the integrator to put the following in writing, and avoid vague promises.

Classification and response

• A clear definition of priority levels, from a stopped month-end or payroll run down to a cosmetic question.
• A response target and a resolution target for each level, expressed in working hours, with your own business calendar in mind (month-end, VAT return deadlines, year-end).
• A named out-of-hours route for critical incidents, with the cost stated.

Scope and exclusions

• Which modules, add-ons, integrations and custom reports are covered.
• Whether users are supported directly or only through a few named key users.
• How you are charged for work that turns out to be a training need rather than a fault. Good training reduces the ticket volume noticeably.

Reporting and governance

• A monthly summary of tickets by category and age, so you can see recurring causes.
• A regular review meeting, with a log of agreed improvements.
• Clear escalation: who at the partner owns your account, and who sits above them.

Integrations

Many incidents do not start in SAP Business One at all but in the connected e-commerce platform, bank feed, warehouse tool or payroll. Settle whether the partner supports those links or only the ERP side. The integrations page lists the typical connection points; make sure each has a named owner.

Hosting changes who answers the phone

If your system runs in the cloud, availability, backups and some security tasks move to the hosting provider. That can simplify support, because one supplier is answerable for the infrastructure, but it adds a contractual relationship to untangle if something fails. Read the hosting and cloud page alongside your support terms, and ask whether the same company is responsible for the application and for the platform. Divided responsibility is the usual reason an incident takes days instead of hours.

What to include in the budget

Without quoting rates, which depend on scope and vary between providers, a realistic UK support budget has distinct lines:

Separate "keeping the lights on" from "improving the system". If both are merged into one monthly fee, you cannot tell whether you are paying for stability or for progress, and neither side has an incentive to be precise. Agree a simple rule for when a request becomes a project, so small changes do not pile up unrecorded.

Be wary of a support contract that looks very cheap because it excludes everything useful, or one that bundles unlimited changes with no governance, which tends to end in disputes. Compare proposals on the same scope sheet. The pricing guide helps you see which costs sit outside support altogether.

Changing your support provider

Changing partner is common, particularly when the original integrator has been acquired, has lost the consultants who knew your system, or no longer responds as it did. It is also achievable, because the licences, data and business processes are yours. Handle it in a sequence:

1. Check your contract. Look at notice periods, any minimum term and what the partner must hand over on exit.
2. Request documentation. This should include a list of customisations, add-ons, scheduled jobs, integrations, user roles and authorisations, and the licence and maintenance details.
3. Commission an independent review if the state of the system is unclear. An audit fixes the starting point so the new provider is not blamed for old faults.
4. Select the new provider with the criteria in our guide to choosing an SAP Business One partner, checking in particular their experience of your sector and your version.
5. Plan the transfer. Agree on test and live access, an overlap period, and an owner on your side for each integration.
6. Close the old arrangements. Remove accounts, revoke remote access and confirm in writing that nothing is left on your servers.

Do not run the handover at month-end or year-end, and keep your own copy of key documents, so you are never dependent on a supplier who may not be cooperating.

Questions to ask before you sign

• Which version are we on, and when must we move?
• Who applies feature packages and support packages, and on what schedule?
• Who supports each add-on and integration, and what happens if the add-on supplier disappears?
• How do you handle HMRC-related changes, payroll and VAT updates?
• What is the exit procedure and what documents will we receive?

If you would like a short list of integrators who support SAP Business One businesses in your region, our service is free and neutral between publishers. We introduce you to suppliers; the support relationship itself is between you and the integrator.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.