Public-sector digital transformation

Operation, Maintenance and Further Development of Digital Systems for Public Institutions

Once a system goes live, the longer part of the work begins: keeping it available and secure, fixing faults and adapting it to new instructions and needs. We provide operation, maintenance and further development on terms set out clearly in the contract, and from day one we work to ensure the institution's team gains the knowledge needed to run the system itself whenever it decides to.

Send a project request WhatsApp

What we offer

Service levels are agreed with the institution in the contract: support hours, classification of incidents by impact, response and resolution times for each class, reporting channels and how performance is reported. We do not publish generic figures in advance; values are set according to the system's importance, available resources and infrastructure conditions, and written so they can be verified.

Beyond fixing faults, we plan releases on a regular basis: improvements and fixes are bundled into releases that are tested in a separate environment, announced in advance and backed by a fallback plan. Change requests follow a written path: the request is logged, its impact and effort are estimated, and the institution approves it before implementation, so small adjustments do not turn into undocumented changes.

The service also covers monitoring of availability, performance and storage, backups according to the agreed schedule, and regular restore tests to confirm that backups can actually be used. In parallel we document operations and involve the institution's team in day-to-day tasks step by step, so that responsibility can be handed over fully or partly according to an agreed plan.

Who it is for

Institutions after launching a new systemWhen structured support is needed in the first months and beyond until use has stabilized.
Bodies with a small technical teamWhen there are not yet enough in-house specialists to run the system alone.
Departments with unsupported existing systemsWhen a system is running without documentation or anyone responsible for maintaining and updating it.
Institutions aiming for operational independenceWhen the goal is to build in-house capacity step by step to take over operations.

Problems we address

Faults reported verbally without logging, classification or follow-up until resolved.
Changes made directly on the live system without testing or documentation.
Backups taken but never tested to see whether a restore actually works.
Unclear boundaries between what support covers and what counts as new development requiring a separate agreement.
Complete dependence on one person or external party without documented knowledge inside the institution.
No monitoring to detect problems before users notice them.

Tasks and deliverables

Service level agreement: A contract annex setting support hours, incident classes, agreed response and resolution times, and how they are measured.
Support ticketing system: A channel for logging incidents and tracking them until closure, with a log the institution can view.
Release plan: A schedule of upcoming releases and their content, with prior testing, user announcements and a fallback plan for each release.
Change request process: A form and procedure for logging a request, estimating impact and effort, and obtaining the institution's approval before implementation.
Monitoring and alerts: Monitoring of system availability, performance and resources, with alerts sent to designated contacts.
Backups and restore tests: Backups according to the agreed schedule and regular restore tests documented with their results.
Periodic operations reports: Summary of incidents and their handling, releases, monitoring and backup results, measured against the service levels.
Operations documentation and knowledge transfer plan: Runbooks and procedures, and a schedule for handing tasks over gradually to the institution's team.

Who does what

What IAG does

Receiving, classifying and resolving incidents according to the agreed service levels.
Planning, testing and deploying releases with a fallback plan.
Estimating change requests and implementing those the institution approves.
Running monitoring, backups and restore tests.
Producing operations reports and documenting procedures.
Training the institution's team and handing tasks over according to the plan.

What specialists, partners and authorities do

The institution approves service levels, change requests and release timing.
The institution decides on the hosting location and who holds administrative and access rights.
The institution appoints a coordinator and an in-house team to take over knowledge.
Hosting or telecommunications providers contracted by the institution are responsible for the services within their remit.

Practical example

Illustrative scenario

First year of operating an internal case-tracking system

An institution has launched a system for tracking internal cases and wants structured support while building in-house capacity to run it.

Sign the service level annex with incident classes and agreed times.
Activate the ticketing system, monitoring and backups.
Regular release of improvements after change requests are approved.
A documented restore test on an agreed date.
Involve institution staff in handling simple incidents.
Annual review to decide which tasks move to the in-house team.

This is an illustrative scenario explaining the approach, not a client reference or an existing project.

How we work together

Takeover and documentation
We review the system, its environment and existing documentation, and record any gaps before the service starts.
Agree service levels
Together with the institution we define support hours, incident classes, times, measurement and reporting.
Activate operations tooling
We set up ticketing, monitoring and backups, and run the first restore test.
Ongoing operation and development
We resolve incidents, implement approved change requests and deploy releases according to plan.
Review and knowledge transfer
We review reports regularly with the institution and gradually hand tasks over to its team.

Intended results

Structured operation that can be measured against written service levels.
Documented and approved changes instead of direct edits with unknown effects.
Greater confidence in restore capability thanks to regular tests.
Growing in-house capacity that allows the institution to run the system itself when it decides to.

What we need from you

A coordinator and an official channel for approving requests.
Information on how critical the system is and when it is used, to set service levels.
The access rights needed for the environment, in line with the institution's rules.
Information on hosting, network and the providers involved.
Staff from the institution who take part in operations to receive knowledge.

Basis for cost and timeline

Cost depends on system size and number of users, the required service levels and support hours, the expected scope of further development and the hosting environment. We usually propose a recurring fee covering support, maintenance, monitoring and backups within the agreed service levels, with a pool of hours or separate pricing for change requests and new development once estimated and approved.

Frequently asked questions

What response times do you commit to?

We do not publish generic times. Times for each incident class are set in the service level annex according to the system's importance and the agreed resources.

What is the difference between maintenance and a change request?

Maintenance restores the system to its agreed behaviour and fixes errors. A change request adds or modifies functionality and needs an estimate and approval before implementation.

Can the institution take over operations later?

Yes, and this is part of the service. We agree a plan for gradually handing tasks and documentation over to the institution's team.

Where are backups stored?

Wherever the institution decides according to its instructions. We document the schedule and the results of restore tests.

Do you support systems you did not develop?

That is possible after a takeover phase in which we review the system, its documentation and access rights, and define what can be supported and on what terms.

Request this service