TECHONE SOLUTION
Cloud Migration with a Controlled Transition
We map each system's dependencies, data and operating requirements. These determine the target environment, required changes and controlled cutover.
When the Current Operating Model Needs to Change
Signs that maintenance alone is no longer enough
The Application Is Increasingly Difficult to Change
Older components, missing documentation or knowledge held by a small number of people make each change take longer.
Infrastructure Constrains Further Operations
The current environment makes expansion into more countries, capacity changes or regular software releases difficult.
Integrations Depend on Unsupported Interfaces
Data transfers rely on local files, older libraries or manual steps that are difficult to monitor and maintain.
Operating Responsibilities Are Unclear
No one has clear ownership of updates, backups, recovery, access and the cost of individual system components.
How We Prepare a Migration
The application, its data and operating model determine each decision
A Separate Path for Each System
Some systems only need a new operating environment. Others require a platform change or a rewrite of the parts that restrict further development.
- Functions and operating rules in active use
- Technical and licensing dependencies
- Required availability and capacity
- Target operating model
Data and Dependencies Before the First Change
We first map databases, files, integrations, user roles and the infrastructure components on which the application depends.
- Data scope and required history
- Mapping and validation controls
- Connections to surrounding systems
- Identities, roles and permissions
A Controlled Cutover
We prepare the sequence of stages, checkpoints and validation of data and critical working scenarios before and after cutover.
- Acceptable downtime
- Responsible owners and result approval
- Conditions for continuing or stopping
- Fallback method supported by the system
Handover to Normal Operations
Before launch, we assign responsibility for monitoring, updates, backups, recovery and continued development.
- Operating documentation and access
- Monitoring of critical components
- Backup and recovery procedure
- Agreed support model after launch
Move, Change the Platform or Rewrite
The same approach does not work for every application. A system built on supported components may move to a new operating environment without changes to its main functions. An application that depends on older libraries or local devices needs changes before it can move.
Where the current code prevents safe maintenance, integration or further development, the migration can include a partial or complete rewrite. We define the scope from the functions people actually use, the data relationships and the capabilities of the target environment.
The cloud platform and its services are selected from these requirements. A provider change alone does not solve constraints that remain inside the application.
Rewriting an Older Application for a Current Environment
Before a rewrite, we map the functions in active use, operating rules, database, integrations and operating-system dependencies. This separates real operating needs from parts that are no longer used.
For Helvetia, we analyzed a Visual Basic backoffice, rewrote the complete system in C# .NET and deployed it to Azure App Service and SQL Database. The rewrite and migration took 18 months.
Each of the seven markets has a separate instance with local adjustments. The markets therefore moved in a controlled sequence, followed by ongoing operating support and development.
Transitioning Data and Operations
Before migration, we agree what data and history will move, how they map to the target model and how the result will be approved. Checks can cover record counts, relationships, balances and selected working scenarios.
The cutover method follows system criticality and acceptable downtime. Where the architecture supports a transition by market, module or user group, each stage receives its own checkpoints.
Temporary parallel operation and a return to the previous version are possible only when data synchronization can be controlled reliably. We therefore define their use in the migration plan from the capabilities of the specific system.
Migration Ends with an Operating Handover
After cutover, we check critical functions, integrations and operating metrics. Documentation must cover the architecture, access, release procedure, backups and recovery.
The handover also assigns responsibilities across the internal team, application supplier and infrastructure operator. Once these points are confirmed, the system can move into normal operations.
If TechOne is also to take responsibility for monitoring, regular maintenance, backups or incident handling, this continues as a separate cloud and infrastructure management scope.
How the Migration Proceeds
From mapping the current system to stable operations in the new environment
Map the System
We document the functions in use, data, integrations, technical dependencies and current operating requirements.
Make the Migration Decision
We determine what can move, what needs a change or rewrite and how the target environment should operate.
Prepare Data and Cutover
We define mapping, validation controls, stage order, responsibilities and cutover conditions.
Deliver in Agreed Stages
We implement the approved changes, transfer data and verify the agreed scenarios before each cutover.
Stabilize and Hand Over
After launch, we check operations, hand over documentation and assign responsibility for management and development.
Migration in Practice
Helvetia: rewriting a Visual Basic backoffice in .NET and moving seven markets to Azure
HELVETIA
E-commerce3+ years
Duration
7
Countries
Frequently Asked Questions
Does the complete application need to be rewritten?
Not always. A supported application may only need a new operating environment or changes to selected components. A rewrite is appropriate where the current code prevents maintenance, integration or further development. The decision follows an analysis of functions in use, data and dependencies.
Can you rewrite an older Visual Basic application?
Yes. For Helvetia, we rewrote the complete backoffice system from Visual Basic to C# .NET and deployed it to Azure App Service and SQL Database for seven European markets. The rewrite and migration took 18 months.
What happens to data during migration?
We agree the data scope and history, mapping to the target model and result controls in advance. A backup and fallback procedure designed for the source system protects the original data. Responsible users approve the transferred data against the agreed checks.
Will the migration affect normal operations?
The impact depends on system criticality, data relationships and acceptable downtime. The transition can use a maintenance window or proceed in self-contained stages where the system allows it. Sequence, checkpoints and responsibilities form part of the migration plan.
How are migration cost and schedule determined?
The scope depends on the application state, number of dependencies and integrations, data volume and quality, required changes and cutover method. After the initial assessment, we divide the work into stages and estimate each one. Target operating costs are calculated separately from the selected architecture and expected workload.
Who manages the environment after migration?
At handover, we assign responsibility for monitoring, updates, backups, recovery and continued development. Operations can remain with the internal team, the current supplier or TechOne. We provide long-term support through Cloud and Infrastructure Management.
Related Services
Other services that might interest you
Start with One System.
In the initial consultation, we discuss the operations, data and integrations of the selected system and define what the initial assessment needs to cover.
Book a Consultation