techone --service=cloud-migration
Cloud Migration
Moving business applications from on-premises to Azure or AWS. We validate the target architecture and cost against the actual workload. Helvetia: an ongoing 3+ year engagement across 7 countries.
Challenges We Solve
When an older system limits development, integration or reliable operation
The system is reaching operational limits
A desktop application or on-premises server can reach capacity and operational limits. Further growth may require infrastructure or architecture changes.
Rising Maintenance Costs
Older technologies may depend on a small number of specialists, unsupported components or knowledge that is not documented.
Parts of the stack are out of support
Unsupported operating systems, libraries or databases make security updates and compliance controls harder to maintain.
Integrations depend on workarounds
The application may lack a supported API or reliable exchange format, leaving data to move through spreadsheets, files or manual entry.
Our Solution
The migration path follows the application, its dependencies and the acceptable operational risk.
Transition designed for the specific system
Depending on architecture, the work can be split by module, function or user group. Cutover may use a maintenance window, temporary parallel operation or another agreed approach.
- Dependencies and operational requirements mapped first
- Pilot or technical proof where it reduces uncertainty
- Data validation and cutover checkpoints
- Fallback conditions defined for the chosen architecture
Controllable Operating Costs
Cloud shifts part of the investment into ongoing consumption and lets capacity follow demand. The final cost depends on architecture, licensing, operations and service configuration.
- Consumption pricing where the service supports it
- Scaling options selected for the workload
- Cost optimization based on actual usage
- Less self-managed infrastructure, depending on the deployment model
From Desktop App to Web
Where a rewrite is justified, we can replace selected VB6, Delphi or FoxPro functions with a current web or service architecture.
- Web access where it fits the user workflow
- Responsive interface for agreed devices
- Supported connections to CRM, e-commerce and other systems
- Documented interfaces for approved integrations
Security and Compliance
Cloud services can provide certified data centers, backup and encryption capabilities. Security and GDPR controls still need to be designed and verified for the complete solution.
- Data encryption at rest and in transit
- Backup and recovery design based on criticality
- Update responsibility defined for each component
- Logging and access control configured for the solution
Migrating Visual Basic and Delphi Applications to Azure
Visual Basic 6, Delphi and FoxPro applications can remain important to a business even when development is constrained by old components, missing documentation or limited integration options. The migration path therefore depends on the code, database and operating environment.
Some applications can move part of their infrastructure without changing the code. Others are better suited to a gradual rewrite or to separating selected functions into new services. Before deciding, we inspect dependencies on COM objects, Windows libraries, local files, databases and peripheral devices.
For a rewrite, we first map the functions and business rules that are still used. Only then do we design the target architecture, data scope and validation method. In the Helvetia project, we rewrote a Visual Basic application into .NET and deployed it in Azure.
Switching to the New System: Chosen Per Project
The impact of cutover depends on system criticality, data volume and acceptable downtime. A less critical application may use a planned maintenance window.
For critical operations, temporary parallel operation or a gradual switch by user group or function may be considered. This requires data synchronization and is not suitable for every system.
Before launch, we define checkpoints, data validation and the conditions under which the transition stops or rolls back. The fallback method depends on the architecture and the capabilities of the source system.
Stable Operations and Infrastructure After Migration
After migration, ownership must be defined for monitoring, backups, updates, costs and incident handling. The project can therefore continue as long-term cloud and infrastructure management.
Operational controls depend on required availability and acceptable data loss. Some applications need monitoring and regularly tested backups; critical systems may require multiple instances, database replication or automated failover, which also add complexity and cost.
Monitoring covers key metrics such as CPU, memory, latency and error rate. For Helvetia's pan-European e-commerce platform, after migration we continue monitoring, supporting and developing the system across 7 countries.
New versions are verified according to the agreed test procedure. The rollback method is prepared for the application technology and any accompanying database changes.
How Much Does Legacy System Migration to Azure Cost
Migration cost depends on the technological complexity of the existing system, data volume and quality, technical debt and the number of integrations.
We therefore base the decision on total cost of ownership: infrastructure, licenses, management, backups, availability, security and future development. A legacy system can be expensive to maintain, but a poorly designed cloud setup can cost more than the current operation.
Consumption-based pricing and auto-scaling can align cost more closely with demand, but savings cannot be promised without a concrete calculation. We prepare the scope, approach and cost estimate after the initial analysis.
How We Work
First, we understand your processes. Then we propose solutions.
Audit and Analysis
We review the current system, code, database, integrations and operating requirements. The depth of the audit follows the available documentation and access.
Architecture and Plan
For each application, we compare retaining it, rehosting, replatforming, rewriting or replacing it. The plan records dependencies, risks and decision points.
Pilot Migration
Where a key assumption is uncertain, we verify it on a selected function, integration or data sample before committing to the wider migration.
Gradual Migration
We deliver the approved stages, verify data and integrations and prepare each transition according to the operating constraints.
Data Migration
We agree what history is required, map the source to the target model and reconcile the transferred data against defined controls.
Launch and Support
We execute the agreed cutover, perform post-launch checks and hand over operating documentation. Ongoing support can follow as a separate scope.
Case Study
Helvetia: Migration from Visual Basic to .NET and Azure
HELVETIA
E-commerce3+ years
Duration
7
Countries
Frequently Asked Questions
How much does cloud migration cost?
It depends on application complexity, data volume, integrations and the target architecture. Cloud can reduce costs, but a one-to-one move can also increase them. Before deciding, we compare total cost across infrastructure, licenses, management, backups, availability and future changes.
How long does cloud migration take?
Duration depends on scope, data quality, integrations, cutover requirements and whether the work is a rehost, replatform or rewrite. We estimate it after the audit and use a pilot module where useful. Helvetia's extensive rewrite and migration took 18 months.
Do you migrate FoxPro, Visual Basic or Delphi applications?
Yes. The appropriate path depends on the code, database, components and operating environment. Options include infrastructure migration, isolating selected functions or a gradual rewrite. For Helvetia, we rewrote a Visual Basic system into .NET and deployed it in Azure for 7 European markets.
What happens to our data during migration?
We agree the data scope, history, relationships and validation rules before migration. Original data is protected according to the approved backup and rollback plan; duration depends on volume, quality and mapping complexity.
Can we migrate only part of the system?
Sometimes. A staged migration works when modules can be separated and data synchronization is manageable. We verify those dependencies before recommending a partial transition.
How do you build a cloud migration plan?
We inventory applications, technologies, data, integrations and operating requirements. For each part, we compare possible strategies such as rehosting, replatforming or rewriting. The output is a plan with priorities, dependencies, a schedule and a cost estimate. The cloud migration guide explains the decision criteria.
Will the migration disrupt our daily operations?
It depends on the system and how much downtime you can tolerate. For less critical systems, a planned cutover in an agreed quiet window - an evening or weekend - is usually enough. For systems that can't go down, we keep the old and new running side by side for a transition period and switch gradually. We choose the approach together during the audit. For Helvetia, after an 18-month rewrite and migration, we continue to support and develop the system across 7 markets.
Related Services
Other services that might interest you
Let's Discuss Your Project We respond within 24 hours.
From analysis to long-term operations. Lagardère: a five-month EDI analysis. Helvetia and Tecam: ongoing development and support.
Request Consultation