Cloud Migration

Visual Basic 6, Delphi and FoxPro are among the most common technologies we encounter during migrations. These applications were typically built between 1998 and 2008, run on Windows Server, use proprietary databases and have no API. While they still work reliably to this day, maintenance costs keep rising and developers for these technologies are virtually impossible to find.

A simple lift-and-shift (moving to a cloud server without changing the code) usually isn't enough for these applications. VB6 components depend on COM objects, Delphi applications on specific Windows libraries and FoxPro on local databases. That's why we take a gradual rewrite to .NET Core, shaped around what the company actually needs today.

We start by mapping existing functionality. We go through the code form by form, document business rules and design the new architecture. We migrate the database to Azure SQL or PostgreSQL with full data validation. You can see what such a project looks like in practice in our Helvetia case study, where we rewrote a Visual Basic application into .NET Core on Azure.

The biggest concern during migration is that operations will stop. How much impact the switch has depends on the system - how critical it is, the volume of data, and how much downtime you can tolerate. That's why we choose the cutover approach per project, not from a single template.

For smaller or less critical systems, a planned cutover in an agreed quiet window is usually enough - an evening or weekend, with a short planned outage you know about in advance.

For operations that can't go down, we keep the old and new systems running side by side for a transition period and switch traffic gradually. It takes more preparation, but the impact on users is minimal.

Whichever path we take, we always have a fallback plan to the original solution ready. We migrate data with validation, the originals stay as a backup, and the whole transition is backed by monitoring and automated tests.

Migration to the cloud is just the beginning. For your application to run reliably, it needs stable operations: monitoring, automatic failover, backups and load-based scaling. After migration we continue with long-term cloud and infrastructure management - monitoring, maintenance, tested backups.

We size operational coverage to what the application needs. For typical workloads, monitoring, regular backups with restore tests and load-based scaling are enough. For critical operations we add failover across multiple servers and database replication, so one server going down does not take the application down.

Monitoring is built on Prometheus and Grafana with dashboards for key metrics: CPU, memory, latency, error rate. That lets us react to problems early, often before they reach users. We applied the same monitoring to Helvetia's pan-European e-commerce platform, where we maintain stable operations across 7 countries.

We automate deployments - every change is tested before it goes live. If something fails, we roll back to the previous version quickly.

Migration cost depends on several factors: the technological complexity of the existing system, data volume and quality, the amount of technical debt in the code, and the number of integrations with surrounding systems.

It's more important to look at migration from a return on investment perspective. Legacy systems carry hidden costs that grow every year: expensive maintenance by specialists in outdated technologies, downtime caused by unreliable infrastructure, missed opportunities due to the inability to integrate modern tools, and security risks from systems without current patches.

After migrating to Azure, operational costs typically drop thanks to the pay-as-you-go model, auto-scaling and elimination of on-premises hardware. You get a system that is scalable, secure and ready for your company's future growth. We discuss migration scope, approach and estimated cost in an initial consultation. After migration, you can further automate processes via AI agents.