Government cloud migration for public institution applications

Problems we solve

We do not start from technology. We start from the situation the institution is actually in — and most of the time it is one of these.

What migrating to the Government Private Cloud actually involves

NERDS.SH does not represent ADR, STS, SRI or DNSC and has no privileged access to the infrastructure they administer. We work on the application and on the infrastructure you control, so that the technical entry requirements are met. The decision to accept an application belongs to the infrastructure administrator.

Services available

Each service has a defined object, deliverables, a timeframe and terms of provision, so it can be assessed, budgeted and contracted without a lengthy discovery phase.

Deliverables are adapted after the initial assessment. We do not recommend Kubernetes for every application — we propose an architecture proportional to the actual need.

From incident to stable operations

Most suppliers cover one step: hosting, web development, maintenance, a vulnerability scan or consultancy. We cover the whole path, and each step ends with something the institution can act on.

1. 01

   Incident or vulnerability

   We take controlled ownership of the infrastructure and make an initial backup, so the data is preserved before anything is changed.

2. 02

   Stabilization

   We isolate affected components, apply immediate fixes and bring the service back into operation.

3. 03

   Audit

   We inventory the code, dependencies, database and integrations, then classify what is migrated, modernized, rebuilt or retired.

4. 04

   Modernization

   We rewrite or replace the components that can no longer be operated safely, while preserving the content and the public archive.

5. 05

   Infrastructure

   We build the infrastructure with Terraform: separated environments, managed secrets, backup and observability.

6. 06

   Migration

   We migrate data and traffic under control, with testing and a rollback plan agreed in advance.

7. 07

   Operations

   We monitor, update, test the restore procedure and respond to incidents on agreed terms.

8. 08

   Handover

   Documentation, operating procedures and knowledge transfer, so the institution is not locked into a single supplier.

The vocabulary, in one line each

These terms appear in every technical specification and every supplier offer. You do not need to master them — but you should be able to tell whether a supplier is proposing something proportionate to your actual need.

Government Private Cloud (CPG)

Servers, storage and networking made available to public institutions in state data centres. You are allocated capacity; you do not buy hardware.

IaaS, PaaS and SaaS

With IaaS you get virtual machines and networking, and the application plus its upkeep stay with you. With PaaS you also get the platform the application runs on. With SaaS you get a finished application. CPG offers all three — and the difference decides who answers when something breaks.

OpenStack

The software that turns a set of physical servers into a private cloud. "Migration to OpenStack" means moving the application onto that kind of platform — not onto a commercial service in another country.

Containers

The application packaged together with everything it needs to run. It starts identically on a developer laptop and in the data centre, which is what makes a migration predictable instead of a gamble.

Kubernetes

The system that starts, restarts and spreads containers across several servers. Useful when the service must survive one server failing. Not necessary for a presentation website — and a supplier who proposes it for one should be asked why.

Terraform / Infrastructure as Code

The infrastructure written down in text files, like a recipe. The environment can be recreated identically at any time and every change is recorded — unlike manual configuration, which nobody can reproduce once the person who did it leaves.

CI/CD

Automated release of new versions. It removes a class of human error and makes going back to the previous version fast.

Backup vs disaster recovery

A backup is the copy of the data. Disaster recovery is the tested procedure by which the service comes back — in how long, and with how much data loss accepted. A backup that has never been restored is not a strategy.

High availability

The application keeps working when a server fails, because it runs in more than one copy. It costs more. It is justified for services citizens use daily, not for every page.

Observability / monitoring

Being able to see at any moment whether the service works, and why it does not. Without it, you find out the site is down from the citizens.

Rollback

Returning to the previous working version when a release goes wrong. It is prepared in advance, not improvised during the incident.

Legacy

An application still in use but built on technology that no longer receives updates. It is not about age — it is about whether it can still be secured and moved.

Frequently asked questions

What is the Government Private Cloud, in plain terms?

Servers, storage and networking made available to public authorities and institutions in state data centres, instead of a machine kept on your own premises or at a commercial hosting provider. ADR is the beneficiary and contracting authority, STS is beneficiary and partner, and SRI is security partner through its National Cyberint Centre. It is funded through the National Recovery and Resilience Plan, Component 7, and provides IaaS, PaaS and SaaS services: you are allocated capacity, you do not buy hardware.

Can we just move our current server there?

Almost never. You do not move the server, you move the application. The infrastructure has entry requirements: components that still receive security updates, an application that can be started automatically, complete source code, defined authentication, tested backups. An application that fails those is refused regardless of available capacity — which is why the readiness audit comes before any migration.

Who decides whether our application is accepted?

The administrator of the target infrastructure. We do not represent ADR, STS, SRI or DNSC and we have no privileged access to what they administer. What we can do is bring the application to the state where the technical requirements are met, and hand over the documentation that shows it.

Our institution is not in the national programme. What now?

The programme’s published targets concern institutions of central public administration, migrated through centrally contracted suppliers. Most local authorities are not in those lots, so preparing the application and choosing a supplier are theirs to handle — which is exactly the work described on this page, and it can be contracted directly under Law no. 98/2016.

Can you intervene if we have already received a vulnerability report or notification?

Yes. We start by taking controlled ownership of the infrastructure and making an initial backup, so the data is preserved before anything changes. We then assess the critical vulnerabilities, isolate the affected components and set out a remediation plan. We commit to rapid mobilization and assessment — not to a fixed resolution deadline decided before the analysis.

How long until we receive an offer?

We reply within the same business day with a preliminary assessment, the recommended service and the steps required for procurement. The technical and financial offer follows once we understand the access available and the actual state of the application.

What if the original supplier no longer responds, or the source code is incomplete?

This is one of the most common situations. We start from what actually exists: the running application, the database, the server configuration. We rebuild the technical inventory, document the dependencies and establish what can be recovered, what has to be rebuilt and what can be retired.

Can the application be moved directly into government infrastructure?

Rarely directly. An application with outdated components, dependencies that cannot be updated, or no automated deployment can be rejected on entry into the new infrastructure. The migration readiness audit establishes exactly what has to be modernized before the move.

Do we need Kubernetes?

Not for every application. For simple sites and portals we recommend an architecture proportional to the requirement. Kubernetes is justified when availability, scaling and operational complexity genuinely call for it.

We have backups. Is that enough?

An untested backup is not a recovery strategy. We test the actual restore, measure how long it takes and document the procedure, so the institution knows the real recovery time before an incident rather than during one.

Can these services be contracted through direct acquisition?

The services are defined with an object, deliverables, a timeframe and terms of provision, so they can be acquired directly under Law no. 98/2016. The decision on the procedure belongs to the contracting authority, based on the estimated value of the entire requirement.

Can you publish the service in the SEAP electronic catalogue?

Yes. On request we send the technical datasheet, the matching CPV code and the item in the SEAP electronic catalogue, together with the technical and financial offer.

Can the content and history of the current website be preserved?

Yes. Taking over and structuring the content, together with migrating the public archive, are part of the modernization package. Preserving the public archive is usually a requirement, not an option.

What happens after the migration?

We can take over operations as a monthly subscription or annual contract: monitoring, updates, backup, restore testing, certificate management, security reviews, reporting and incident management.