Ampla support in Australia should cover seven things: scheduled health checks, model maintenance as the plant changes, reason code and report upkeep, interface monitoring, capacity and licence planning, documentation and site training, and a monthly allocation for improvement. Incident response is only one part. A contract that covers only call-outs keeps the system running while it slowly gets worse.
Key takeaways
- Ampla and AVEVA Production Management environments degrade quietly: a slower SQL backend, a model that drifts from the plant, interfaces that drop records, and knowledge that leaves with people.
- Most support contracts are written around availability, so the slow problems sit with nobody.
- A useful managed service names an owner for the condition of the system, with written health check output on a cycle.
- On a system nobody has documented, do discovery first and change nothing until the baseline is written.
- Plan upgrades against AVEVA's published lifecycle policy and sequence them with IT.
Why does a "fine" Ampla system still need support?
Ask a site whether their Ampla environment needs attention and the answer is usually no. It is up, data is flowing and the reports come out. There is a support contract with a phone number on it, and nobody has called it in months.
That only tells you nothing has broken loudly. An Ampla or AVEVA Production Management environment degrades in ways that never trigger a call. By the time something breaks loudly enough to justify one, you are dealing with several years of drift at once.
This guide is for plant systems engineers, production superintendents and the operations managers who sign the renewal. Across our consultants' careers, including production and reporting systems work in BHP, Rio Tinto and Senex Energy environments, the most common pattern is a site paying for reactive support and getting no improvement in return.
What degrades in an Ampla environment over time?
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 build up for every piece of equipment, every shift, for as long as the system has run.
Performance does not fall off a cliff. Screens load a little slower. A report that ran in 20 seconds takes 90. The overnight summary job starts overlapping the morning. Nobody raises a ticket, and people start avoiding the system in busy periods.
The fixes are ordinary database work: index maintenance, statistics, an archive or purge strategy that matches the site's real retention obligations, and storage sized for growth. None of it is hard. It needs 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 swapped, circuits are rerouted, new lines are commissioned, and debottlenecking changes the rates everything is measured against.
Each change should produce a small amount of model work. Usually it does not, because the change runs as an engineering project and production systems are nobody's line item. The numbers become less descriptive of the plant every year. The same decay hits the reason code tree, covered in our Ampla delay accounting guide, and the historian model underneath, where PI Asset Framework template design decides how painful the next plant change will be.
Interfaces fail silently
This failure 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 degrades rather than stops, nothing complains. Records arrive with gaps. A tag mapping breaks after a controls change. An ERP integration fails on a subset of transactions and the error goes to a mailbox nobody reads.
A site can run for months on a production figure that quietly excludes one line. Interface monitoring is the cheapest insurance in this category, and in practice it means three checks and one name:
- A daily record count per 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 weekly reconciliation of event counts against the source system.
- A named person who receives the alert and is expected to act on it.
Building that takes a day or two. Finding out in November that one line has been missing since July costs far more, in credibility as well as rework.
Reports nobody maintains
Report libraries accumulate. A report is built for one question, the question changes, the report stays. Years later there are ninety reports, a dozen in use, and several giving slightly different answers to the same question because they use different definitions.
When two reports disagree, the meeting stops being about the plant. Somebody builds a spreadsheet to settle it, and that spreadsheet becomes the real reporting system, kept by one person and outside every control the site has.
Version and platform obsolescence
Ampla runs on Windows Server, SQL Server and .NET, each with its own lifecycle. AVEVA's software lifecycle and retirement policy (June 2025) sets a maximum of three years of full support from release, up to two further years of security-only support, then technical assistance until end of life. A version six or seven years old is outside the window where fixes are produced.
The exposure usually arrives from underneath. A Windows or SQL upgrade forced by IT security policy lands on a version never certified against it, and a routine patch becomes an unplanned outage of production reporting during month end.
Knowledge leaves with people
The decisions that make an Ampla environment understandable usually live in one or two heads: why the calendar is set up that way, why a unit sits under an unexpected parent, which of three similar reports finance uses. When those people leave, the next person makes a reasonable-looking change that breaks a rollup nobody knew depended on it. This is the "if Sam leaves we're stuffed" problem in its purest form.
| Break and fix contract | Maintained arrangement | Impact | |
|---|---|---|---|
| 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 | Key-person risk |
What should an Ampla support contract cover?
Support contracts for production systems tend to be written as incident response, because it is easy to define. It also adds the least value, because by the time an incident exists the damage is done. A managed service worth paying for covers seven things:
- Scheduled health checks. A standing review of the database, interfaces, job schedules, error logs and growth trend, on a cycle, with written output.
- Model maintenance as the plant changes. A route by which a plant change produces a matching change to the hierarchy, rates, calendars and reason codes.
- Reason code and report upkeep. Retiring dead codes and unused reports, and keeping definitions consistent so two reports of the same thing agree.
- Interface monitoring. Automated record count and freshness checks on every integration, alerting a person who acts.
- Capacity and licence planning. Tracking storage, server capacity and licence counts against where the site is heading.
- Documentation and site training. A current description of how the environment is configured and why, plus enough capability in the site team for routine work.
- Continuous improvement. A standing monthly allocation to make something better.
To test what you are buying now, look for the clause that obliges someone to do each of those seven. Incident response will be there with a response time. Patching may be. The rest usually are not, which means the site carries them, and on most sites that means nobody does. Fix it at the next renewal by writing each item into scope with an hours allocation and asking for health check output in writing.
Which of these describes your Ampla environment right now?
- Works, nobody owns itHealth check first, then a light retained arrangement to stop the drift
- Original builder has leftBrownfield discovery and documentation before any change work
- Version well past supportUpgrade assessment and a platform roadmap, sequenced with IT
- Numbers are being disputedModel and definition review, starting with reason codes and rates
- Frequent interface failuresIntegration review and monitoring, usually the quickest fix available
Can you take over an Ampla system somebody else built?
Yes. Most Ampla work in Australia is brownfield. The system was implemented years ago by a vendor or integrator, the handover either did not happen or went to someone who has left, and what exists is a working system with no reliable description of itself.
The failure mode is to start changing things. Someone sees something that looks wrong, corrects it, and finds two weeks later that a rollup feeding the board pack depended on it. Every oddity in a long-lived production system is either a mistake or a deliberate workaround, and you cannot tell which by looking. So the first phase is discovery, and nothing changes during it.
- InventoryVersions, servers, databases, services, licences, what is actually deployed
- Map integrationsEvery interface in and out, what feeds it, what depends on it
- Walk the modelCompare the equipment hierarchy against the physical plant on site
- Audit reportsWhat exists, what is used, what definitions they disagree on
- Interview usersOperators, supervisors, planners, finance. Where the workarounds are
- Document and prioritiseA written baseline, then a ranked list of what to fix first
Two steps carry most of the value. Walking the model against the plant is the only way to measure drift, and it has to happen on site with someone who knows the plant. Interviewing users is how you find the shadow spreadsheet the production meeting actually runs on, which tells you 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, and to produce more findings than you can act on in a year. That is the point: you get to choose.
- Weeks 1-4DiscoveryInventory, integrations, model walk, report audit, user interviews. No changes.
- Week 5Baseline and planWritten description of the environment, ranked findings, agreed priorities
- Weeks 6-8StabiliseInterface monitoring, database maintenance, retire the obviously dead
- Weeks 9-12First improvementsFix the highest-value model or report problem, train the site team on it
- OngoingRetained cycleHealth checks, model maintenance as the plant changes, monthly improvement
Is retained support better than a break and fix contract?
A reactive contract pays someone to respond when something breaks. That is fair and it does what it says. Nothing in it obliges anyone to notice the slow problems or improve anything. The database keeps growing, the model keeps drifting and the reports keep multiplying, until one of them surfaces as an incident that costs far more than the maintenance would have.
The result is a site paying for support every year and arriving at year five with a system measurably worse than at year one. A retained arrangement changes what is bought: ownership instead of response time. Somebody's standing job includes the health of the environment, they know what changed on site last month, and they have time each month to improve something.
The same logic applies to any system integration layer and to process automation generally: the build is a fraction of the lifetime cost, and the part nobody budgets for decides whether it is still useful in five years.
How is a managed Ampla service scoped?
Retained support for an Ampla or AVEVA Production Management environment is scoped on three variables: the size of the estate, the response level you need during and outside production hours, and how much of the monthly allocation goes to improvement rather than maintenance.
- Environment sizeSites, servers, databases, interfaces
- Response levelBusiness hours, extended, or production-hours cover
- Maintenance allocationHealth checks, database, interfaces, patching
- Improvement allocationModel, reports and reason code work each month
- Upgrade planningRoadmap against the vendor lifecycle
A single site on business hours cover is a smaller scope than a multi-site estate needing production-hours cover. Compare any proposal against what your current arrangement costs you, including the crisis projects it has not prevented.
On a system nobody has looked at in years, do discovery first. A four-week brownfield assessment gives both sides a documented baseline and a ranked list of findings, which is what the ongoing scope should be built on. We work as a fixed fee per phase, agreed before we start, and you can stop after any phase.
How do you plan an Ampla upgrade?
Plan it against the vendor lifecycle and sequence it with IT rather than around them. Map your Ampla version, Windows Server and SQL Server versions against their support dates, identify which will be forced first by security policy, and schedule the upgrade outside month end with a tested rollback. Treat it as a project with its own discovery, not a patch.
How Solve8 can help
Our consultants and engineers provide retained support and improvement work across Ampla and AVEVA Production Management, PI and AVEVA Historian, SCADA and the integration layers between them. Our managed services are built around maintenance and improvement, within our mining, resources and manufacturing practice. If you want a view on your environment, talk to us and we will look at it before proposing anything.
