What Ampla Support Should Actually Cover
The System Is Fine, Which Is the Problem
Ask a site whether their Ampla environment needs attention and the answer is usually no. It is up. Data is flowing. The reports come out. There is a support contract in a drawer with a phone number on it, and nobody has needed to call it in eight months.
All that tells you is that nothing has broken loudly, which is a different claim from health. An Ampla or AVEVA Production Management environment degrades in ways that never trigger a phone call: the SQL backend gets slower by a few percent a quarter, an interface starts dropping records without alarming, the model falls further behind the physical plant every time something changes on site, and the person who understood how it was all configured takes another job. By the time something breaks loudly enough to justify a support call, you are dealing with several years of accumulated drift at once.
This post sets out what actually degrades in these environments, what a support arrangement should cover if it is going to be worth paying for, and how to take over a system that somebody else built and nobody documented. It is written for plant systems engineers, production superintendents and the operations managers who sign the renewal. Across 18 years of industrial data and OT work, including production and reporting systems projects delivered for BHP, Rio Tinto and Senex Energy while employed by other consulting and engineering firms, the pattern that shows up most often is a site paying for reactive support and receiving no improvement in return.
What Actually Degrades
The SQL backend grows and slows
Ampla stores everything in SQL Server, and the volume only goes one way. Sample data, downtime records, production records, audit history and workflow state accumulate for every piece of equipment, every shift, for as long as the system has been running. A plant that has been live for eight years is carrying eight years of it.
Performance does not fall off a cliff. Screens take a little longer to load. A report that used to run in 20 seconds takes 90. The overnight job that populates the production summary starts occasionally overlapping the morning. Nobody raises a ticket for any of it, because each step is small enough to absorb, and the cumulative effect is a system that people avoid using during busy periods.
The fixes are ordinary database work: index maintenance, statistics, an archiving or purge strategy that matches the site's actual retention obligations rather than keeping everything forever, and storage sized for growth. None of it is difficult. It requires somebody whose job includes looking.
The model falls behind the plant
Ampla's equipment hierarchy is a model of the physical plant, and the plant keeps changing. Equipment is replaced with different equipment. A circuit is rerouted. A new line is commissioned. Capacity is debottlenecked, which changes the rate that everything is measured against.
Every one of those changes should produce a small amount of work in the model. Most of the time it does not, because the change is managed as an engineering project and the production systems are nobody's line item. The model stays as it was, and the numbers it produces get progressively less descriptive of what the plant is doing. The same decay hits the reason code tree, which we cover in detail in the Ampla delay accounting model guide, and it hits the model layer in the historian below it too, where PI Asset Framework template design determines how painful the next plant change will be to absorb.
Interfaces fail silently
This is the failure mode that costs the most and gets noticed the least. Ampla depends on interfaces to SCADA, the historian, the ERP and sometimes the laboratory system. When one of those degrades rather than stops, the system does not complain. Records arrive with gaps. A tag mapping breaks after a controls change and one piece of equipment stops reporting state. An ERP integration starts failing on a subset of transactions and the error goes to a mailbox nobody reads.
The numbers keep coming out. They are just missing things. A site can run for months on a production figure that silently excludes one line, and the discovery usually happens during a month end investigation into something else. Interface monitoring, with an actual alert to an actual person when record counts deviate from expectation, is the cheapest insurance in this whole category and it is missing from most sites.
In practice it means three checks and one name. A daily record count for each interface, compared against an expected band for that day of the week. A freshness check confirming the newest record is no older than the interface cycle. A reconciliation of event counts against the source system on a weekly cycle. And a named person who receives the alert and is expected to act on it. Building that takes a day or two of work. Discovering in November that one line has been missing from the production figure since July costs considerably more than that, and it costs it in credibility as well as in rework.
Reports nobody maintains
Report libraries accumulate. Somebody builds a report for a specific question in 2019, it gets used for a while, the question changes, the report stays. Five years later there are ninety reports in the library, a dozen of which are used, several of which produce subtly different answers to the same question because they were built against different definitions.
That last part is where it becomes expensive. When two reports disagree, the meeting stops being about the plant and starts being about the reports. Somebody builds a spreadsheet to settle it, and that spreadsheet becomes the real reporting system, maintained by one person, sitting outside every control the site has.
Version and platform obsolescence
Ampla runs on Windows Server, SQL Server and a .NET stack, and all of those have their own lifecycles moving underneath it. AVEVA's software lifecycle and retirement policy, published in its current form in June 2025, sets out a maximum of three years of full support from a release date, up to two further years of security-only support, then technical assistance until end of life. A site running a version that is six or seven years old is outside the window where fixes are produced, and is usually also running an operating system or database version with its own support problem.
The exposure usually arrives from underneath rather than from Ampla itself. A Windows or SQL upgrade forced by IT security policy lands on a version that was never certified against it, and what was meant to be a routine patch becomes an unplanned outage of the production reporting system during month end.
Knowledge leaves with people
The configuration decisions that make an Ampla environment comprehensible mostly live in one or two heads. Why the calendar is set up the way it is. Why that piece of equipment is modelled under a different parent than you would expect. Which of the three similar reports is the one finance uses. What the workaround is for the thing that has never quite worked since 2021.
When those people leave, the system does not change but it stops being understood, and the next person to touch it makes a reasonable-looking change that breaks a rollup nobody knew depended on it.
Break and fix against a maintained arrangement
| Metric | Break and fix contract | Maintained arrangement | Improvement |
|---|---|---|---|
| Trigger for work | Something visibly stops working | Scheduled health checks plus incidents | Failures prevented |
| SQL backend | Untouched until performance complaints | Index, archive and growth managed on a cycle | Report run times |
| Plant changes | Model updated when someone notices it is wrong | Model change scoped alongside the plant change | Model accuracy |
| Interfaces | Detected when a number looks wrong at month end | Monitored, with record count alerts to a person | Time to detect |
| Reports | Library grows, nothing is retired | Reviewed, rationalised, definitions documented | Reports in use |
| Version currency | Upgrade becomes a crisis project | Roadmap tracked against the vendor lifecycle | Unplanned outages |
| Site knowledge | Held by one person, lost when they leave | Documented and trained into the site team | Bus factor |
What a Useful Arrangement Covers
Support contracts for production systems tend to be written as incident response, because incident response is easy to define and easy to price. It is also the part of the work that adds the least value, because by the time an incident exists the damage is done.
A support arrangement worth paying for covers seven things, and incident response is only one of them.
- Scheduled health checks: a standing review of the database, the interfaces, the job schedules, the error logs and the growth trend, on a cycle, with a written output. Most preventable failures are caught here.
- Model maintenance as the plant changes: a route by which a change to the physical plant produces a matching change to the equipment hierarchy, the rates, the calendars and the reason code tree, before the numbers start lying.
- Reason code and report upkeep: retiring dead codes and unused reports, keeping the tree usable, and holding report definitions consistent so that two reports of the same thing agree.
- Interface monitoring: automated checks on record counts and freshness for every integration, with alerting that reaches a person who is expected to act on it.
- Capacity and licensing planning: tracking where storage, server capacity and licence counts are heading against where the site is heading, so that neither becomes an emergency purchase.
- Documentation and site training: maintaining a current description of how the environment is configured and why, and putting enough capability into the site team that routine work does not require a phone call.
- Continuous improvement: a standing allocation of time each month to make something better rather than to fix something broken.
A quick way to test what you are currently buying is to take your existing agreement and look for the clause that obliges someone to do each of those seven. Incident response will be in there with a response time attached. Patching may be. The other five usually are not, which means the site is carrying them, and on most sites that means nobody is. The vendor is delivering what was written down, so the gap sits in how the contract was scoped: around availability, rather than around the condition of the system. It is fixable at the next renewal by writing the remaining items into scope with an allocation of hours against each, and by asking for the health check output in writing.
What kind of arrangement fits your situation
Taking Over a System Somebody Else Built
Most Ampla engagements in Australia are brownfield. The system was implemented years ago by a vendor or an integrator, the handover either did not happen or happened to someone who has since left, and what exists on site is a working system with no reliable description of itself.
The failure mode when taking one of these over is to start changing things. Someone looks at the model, sees something that appears wrong, corrects it, and discovers a fortnight later that a rollup feeding the monthly board pack depended on the thing that appeared wrong. Every configuration oddity in a long-lived production system is either a mistake or a deliberate workaround, and you cannot tell which by looking at it.
So the first phase is discovery, and nothing gets changed during it.
Brownfield Ampla takeover, discovery sequence
Two parts of that sequence carry most of the value. Walking the model against the physical plant is the only way to find out how far it has drifted, and it has to be done on site with someone who knows the plant, not from a desk with a P&ID. Interviewing users is how you find the shadow system: the spreadsheet that the production meeting actually runs on, which tells you exactly which questions the official reports have stopped answering.
Expect discovery on a single-site environment to take three to four weeks of part-time effort. Expect it to produce more findings than you can act on in a year, which is fine, because the point of the exercise is to be able to choose.
First 90 days of an Ampla takeover
Why Most Sites Get No Improvement
If you hold a reactive support contract, the vendor or integrator is paid to respond when something breaks. That is a fair arrangement and it does what it says. But nothing in it creates an obligation on anyone to make the system better, and nothing in it creates an obligation on anyone to notice the slow problems. The database will keep growing. The model will keep falling behind the plant. The reports will keep accumulating. Every one of those is invisible to a contract that activates on incidents, and every one of them will eventually surface as an incident that costs far more than the maintenance would have.
The result is a site spending money on support every year and arriving at year five with a system that is measurably worse than it was at year one. The spend was real enough; the improvement was never in scope.
A retained arrangement changes what is being bought. Instead of buying response time, you are buying ownership: somebody whose standing job includes the health of the environment, who knows what changed on site last month and what that means for the model, and who has time allocated each month to improve something. It costs more per month than a call-out contract and less per year than the crisis projects it prevents.
The same argument applies to any system integration layer and to process automation work generally: the build is a fraction of the lifetime cost, and the part nobody budgets for is the part that determines whether the thing is still useful in five years.
Scoping and Cost
Retained support for an Ampla or AVEVA Production Management environment is scoped on three variables: the number of sites and servers in the estate, the response level you need during production hours and after them, and how much of the monthly allocation goes to improvement rather than maintenance.
How retained OT support is usually scoped
The range depends mostly on response level and estate size. A single site on business hours cover sits at the lower end. A multi-site estate needing cover across production hours sits higher. Our full pricing approach sets out how we scope this, and it is worth pricing against what your current arrangement costs you including the projects it has not prevented.
Before committing to a retained arrangement on a system nobody has looked at in years, do the discovery first. A four week brownfield assessment gives you a documented baseline and a ranked list of findings, and it tells both sides what the ongoing scope should actually be. Buying a monthly arrangement without it means guessing.
Where to Start
If your Ampla environment has been running without attention for more than two years, if the person who configured it has left, or if your reports have been replaced in practice by a spreadsheet that one person maintains, the useful next step is a health check rather than a contract negotiation. Find out what state the environment is in, then decide what it needs.
Solve8 provides retained support and improvement work for Australian industrial operators across Ampla and AVEVA Production Management, Citect SCADA, PI and AVEVA Historian, and the integration layers between them, drawing on 18 years of hands-on OT experience. Our managed AI and OT support service is built around maintenance and improvement rather than incident response alone, it sits within our broader operational technology and manufacturing capability, and we work with resources and industrial operators from Brisbane across Queensland and nationally. If you want a view on what shape your environment is in, start a scoping conversation and we will look at it before proposing anything.