Legacy software modernization services

Legacy software modernization, also called application modernization, is changing the stack, architecture or infrastructure of a working application without losing what already works. Our application modernization services use the usual strategies: replatforming, refactoring and framework upgrades, changing the architecture and replacing a single module. The same work often includes changing the database engine and describing infrastructure in code. We do it under Platform & Cloud Engineering, next to our wider Custom Software Development.

• Replatforming. We moved the backend that loads and processes data from Zeronest's modems (ETL) from AWS Lambda and DynamoDB to Django, PostgreSQL and Celery, as described below.
• Refactoring. In September 2025 we refactored the ETL that processes Zeronest's device readings.
• Framework upgrades. Enerace moved to Python 3.13 and Django 5 between April and June 2025, and its mobile app got a newer React Native between February and March 2026. A client in the industrial sector moved its front end from Vue 2 to Vue 3, from Vuetify 3 to Vuetify 4 and to Vite. Our team rated Vue 3 as a clear improvement over version 2 and the move to Vite as a definite plus.
• Changing the architecture. On the industrial client's platform, new functions are built as microservices in Django and FastAPI.
• Changing the database engine. In 2025 a vendor of software for monitoring centers moved its product from MS SQL to PostgreSQL on Windows. We prepared the deployment procedures and configuration and migrated the schema and the data. We analyzed the SQL dialect changes in the Pascal code and automated them. We also trained the client's team in PostgreSQL and its administration, and designed replication, failover and high availability.
• Infrastructure as code. At Skyfri we introduced Terraform next to the ARM Templates and Azure CLI scripts the client already used, starting with the notifications MVP. By the November 2024 retrospective, the number of services with full CI/CD and infrastructure as code was growing.
• Replacing a module. At Skyfri we are building a new IoT system on Azure IoT Hub and IoT Edge, meant to replace the current system that collects data from devices. In the same project, interface components go into a library that grows with the product, Mock Service Worker lets the front end run against mocked API responses before the backend exists, and the energy management system supports many batteries because it was built in modules.

Which systems and applications we modernize

Most systems that need modernizing run on several technologies. The industrial client's platform, which we took over, combines .NET, Ruby on Rails, FastAPI, Django, Vue, Android and iOS apps and Terraform. A mixed stack is a normal starting point for us, so we plan the work module by module. When the Skyfri audit began, the stack was React, C# and ASP.NET, Python and pyspark, Kusto/ADX, Databricks and Azure.

The applications in scope are web front ends, backend services and data pipelines, mobile apps for Android and iOS, and the infrastructure under all of them.

A modernization starts with an audit of the client's current products and stack. At Skyfri in Oslo the audit ran from 20 November 2023 to 7 January 2024. The client asked us to point out what to change in the product build process and in performance, so we looked at the existing projects and the whole stack.

After the audit we set the order of changes together with the client. We work as part of the Skyfri team, next to the colleagues in Oslo.

Rewrite or step by step? What works stably stays, and new functions go into new modules. On the industrial platform, the older .NET and Ruby on Rails elements run stably, so they stay in the system and change gradually, while the new modules are written in Django and FastAPI.

The code is yours. Copyrights pass to you with each payment and you receive the source code. The working repository we use stays in our controlled environment.

At Zeronest we changed running software in stages. In the first week of August 2024 the Django backend started as a new application, with automated deployment to AWS ECS and sign-in through AWS Cognito and the installation models. The new ETL process for modem data was built in September and October 2024. The old Lambda, scheduler and DynamoDB were switched off first in the development environment and then in production, between December 2024 and April 2025. The data moved over in four stages:

1. Start: in September 2024, charts built from inverter and meter data still read from the DynamoDB readings table.
2. From October 2024, a Celery job running every 2 minutes wrote the processed readings to PostgreSQL.
3. From January 2025, the ETL fetched device readings straight from the IoT platform API and stored them in PostgreSQL.
4. A week later, the readings endpoints read from PostgreSQL.

The ETL stores the raw device readings, so the processed data can be recalculated later from what was stored. DynamoDB no longer appears in the backend code. Updates continued on the live system: the Android target API level in August 2025 and React Native between April and July 2026.

One Django and PostgreSQL backend runs the whole Zeronest data flow: readings, alerts, aggregates, forecasts, inverter control and notifications. It fetches, validates and merges device readings, calculates aggregates every minute, 15 minutes, hour and day, and downloads day-ahead market tariff prices with price statistics. It also produces the day-ahead forecast and sets up new installations. Our team's technical retrospective in February 2025 listed the ETL on Django and PostgreSQL among the things that worked well, together with the complete automated deployment process.

Data and alerts

Two alerts watch the ETL. One fires when the ETL job for a modem fails to run 4 times within an hour, the other when the newest modem data in the database is more than 20 minutes old.

When the readings of one device in an installation arrive late, the ETL loads the stored readings of the second device, merges them again and updates the merged modem data.

The data model allows several inverters per installation, one of them the main one, and the ETL fetches the main inverter's data. Support for two inverters in the ETL was added in September 2026.

Inverter control profiles are edited in the admin panel, with validation, preview and instructions, next to the modules for individual manufacturers. Tests check that the sample profiles reproduce the behavior of the existing modules.

Operations

Since July 2026 background tasks have run on four Celery queues with separate workers: main, device management, ETL, and aggregates and predictions. Inverter control runs every minute, aggregates run on a schedule and the inverter state forecast runs every hour. The ETL kept growing after the platform change, with alerts in January 2025, minute aggregates in June 2025 and, in August 2026, separate pipelines for the DIN 200 and DIN 300 modems.

There were 25 tagged releases between v5.0.0 in November 2024 and v7.5.0 in November 2025, about one every two weeks. The backend has more than 1,500 automated tests, CI runs lint, format checks and the tests on PostgreSQL for every pull request, and a GitHub Actions pipeline builds the Docker image, pushes it to ECR, runs the Terraform backend module and a post-deployment script.

Enerace has grown in one application since 2019: users, market data, contracts, formulas, documents, invoices, tenders and, since January 2026, energy production data.

The platform under it was updated along the way:

• Infrastructure. The first AWS setup in CloudFormation, with a VPC network and an RDS database, dates from November 2019, and Redis on ElastiCache followed a month later. The ECS Fargate environments have been described in Terraform since February 2023.
• CI/CD. GitLab CI has run since November 2021. Since August 2024, GitHub Actions builds the Django and Nginx images, pushes them to ECR and deploys with Terraform.
• Versions. Django 3.2 in 2022, then Django 5.2 and PostgreSQL 16.9 in spring 2025. The base image moved to Debian Trixie in September 2026, and Terraform set PostgreSQL 17.11 for production and staging in October 2026.

We work on AWS, Azure and Hetzner. For cloud migrations we default to AWS with Terraform, because we think AWS has the best tooling. Azure is another platform we use, and Skyfri is the example. See Cloud Application Development for the wider scope.

After a modernization the system can stay with us under an SLA set in the contract, as described under Support & Maintenance. Hypercare after release is possible, and we agree its scope and duration before the start. How we handle access and data is described on the Security & GDPR page.

Write to us through the contact form or book a free discovery call. We reply within 48 hours on working days. The basic discovery is a free meeting. For anything larger, our discovery workshops cover the scope, a roadmap and an estimate of cost and time.