Infrastructure modernisation and cloud

What we do

1. 01

   New infrastructure from scratch (greenfield)

   For a new product or project there is nothing to migrate. We design the infrastructure, build it in IaC and launch it with everything operations need from day one. Then we hand it over with documentation, or take it into long-term operations. We build:

   • an architecture that fits the application, expected load and budget
   • an environment in the cloud, on your own servers, or both
   • separate environments for development, testing and production
   • CI/CD and GitOps for deploying applications
   • identity and access, monitoring, logging and backups
   • documentation and training, or ongoing operations by us
2. 02

   Current state assessment

   We talk to the people who run the environment today and look at how the systems really are, not only at the documentation. The output is an overview of the environment, a list of risks ranked by impact and a recommendation on where to start. You keep the output whether or not the engagement continues. We map:

   • servers, virtual machines and cloud services, including the ones little is known about
   • applications, databases and how they depend on each other
   • the network, services exposed to the internet, and access, including suppliers
   • backups, and what happens when a part goes down
   • what you spend on cloud, hosting and licences, and on manual work
   • the age of systems and the end of life of operating systems, databases and frameworks
   • what only one person knows and what is missing from the documentation
3. 03

   Comparing options

   Cloud, your own servers, or both. Technology is chosen to fit your applications and team: if a simpler solution is enough, we keep it. Every recommendation comes with the reasons. We compare the options on:

   • the cost of running it and the cost of the change itself, with a cost estimate
   • risks and the impact on availability
   • the operational effort for your team
   • data location and regulatory requirements (for example GDPR, NIS2)
   • supplier lock-in, and how easy it is to leave later
   • whether you can move gradually instead of in one big step
4. 04

   Target architecture design

   We design the target state to fit your applications, team and budget, and write down why it is designed that way. The design covers:

   • the network and its zones, office connections and remote access
   • identity and access: single sign-on (SSO), roles and separate administration
   • compute: virtual machines, containers or managed services
   • databases and storage, including encryption and backups
   • monitoring, logging and alerting
   • how applications are deployed (CI/CD, GitOps)
   • budget, cost labels per project and limits, so the cloud bill holds no surprises
5. 05

   Migration plan

   We split the migration into smaller steps that can be deployed and verified on their own. The impact on operations is assessed in advance, without a one-off switch-over of the whole environment. Each step comes with:

   • an order based on dependencies and risk, starting with the least critical applications
   • a test that confirms everything works after the move
   • a way back if the check fails
   • a slot outside your peak hours and an agreement on who is available at the time
   • a procedure for moving data and keeping it in sync during the transition
   • shutting down and cleaning up the old environment once the new one is verified
6. 06

   Infrastructure as code

   The resulting environment is described as code and changes go through GitOps. The environment can be rebuilt from code at any time, and every change has an author, a review and a history. We put in place:

   • Terraform or OpenTofu for cloud, network and services
   • Ansible for server configuration
   • changes through a merge request with a preview of the impact (plan) and approval
   • infrastructure state stored securely, with locking and history
   • automatic deployment of approved changes from CI/CD, with short-lived access
   • checks that the real state hasn’t drifted from the code
7. 07

   Documentation and handover

   We write down what the code doesn’t show, so management does not depend on one person. You own the code and the documentation. We hand over:

   • an architecture overview and the reasons behind the main decisions
   • procedures for everyday situations and for recovery after an outage
   • a list of access and who is responsible for what
   • training for your team, so they can make changes themselves
   • if agreed, ongoing operations by us, or consultations when you need them