The availability of high-performance GPUs that drastically speed up computations in many different domains gives a new push to the idea of migrating legacy systems’ CPU algorithms to their GPU counterparts to benefit from the speedups. Migrating existing CPU-based C/C++ code to GPU-accelerated implementations (CUDA® or similar models) is not primarily a syntactic transformation. It is an architectural intervention. Not limited to safety-regulated systems, e.g. in medical devices or automotive, the challenge is not only about rewriting functions but also about preserving system integrity while introducing a fundamentally different execution model.
A disciplined approach is required to control risk, maintain correctness, and ensure long-term maintainability. This post outlines a method that combines architectural analysis with continuous verification and CUDA-specific safety enforcement.
A migration effort without architectural visibility tends to degrade system structure. Therefore, the first step is to establish a reliable architectural baseline.
If a formal software architecture already exists, it should be validated against the current implementation using Axivion’s architecture verification capabilities. This step ensures:
Conformance between intended and actual structure
Identification of erosion or drift
A stable baseline for subsequent migration decisions
This baseline acts as a contract. Any GPU-related changes can later be validated against it.
In many legacy systems, architecture documentation is non-existent, incomplete, or outdated. In such cases, architecture recovery is required.
Axivion’s architecture recovery extracts a structural model directly from the codebase, including:
Component boundaries
Dependency graphs
Layers and subsystems
The recovered architecture is then refined into a working model that serves the same purpose as a documented architecture: a reference point for controlled evolution. This recovery step can benefit from the assistance of available domain experts - and from the use of GenAI.
Not all components are suitable for GPU migration. Selection should be based on computational characteristics such as:
Data parallelism
High arithmetic intensity
Low branching complexity
Once candidate components are identified, their interfaces must be explicitly defined and stabilized.
GPU migration often introduces:
Memory boundary changes (host ↔ device)
Data layout transformations
Asynchronous execution semantics
Without clearly defined interfaces, these changes propagate unpredictably through the system.
In addition, insufficient architectural control commonly leads to:
Accidental tight coupling between components
Forgotten or implicit dependencies resurfacing during refactoring
Violations of intended layering and component boundaries (thinking of “Freedom from Interference” between components of different safety integrity levels)
Using Axivion’s architecture tooling, teams can:
Document component interfaces
Enforce dependency constraints
Support systematic decoupling of components
Detect and eliminate hidden or unintended dependencies early
This step effectively isolates migration scope and reduces systemic risk.
Migration should proceed incrementally, not as a single large transformation. Each iteration introduces GPU functionality while maintaining system correctness.
After each iteration:
The updated codebase is checked against the architectural model
Violations (e.g., new dependencies, layer breaches) are detected early
Missing dependencies are identified
Structural degradation is prevented
This ensures that changes due to GPU integration does not compromise the overall system design. Furthermore, an automated comparison between old and new architecture can reveal if the GPU-based implementation interacts with the overall system in the same way the CPU-based component did. Any diversion might indicate that the newly developed component is not as much a “drop-in replacement” as desired.
GPU programming introduces new classes of flaws that are not present in CPU-only systems. To address these, CUDA-specific safety rules must be applied consistently across both legacy and newly introduced code.
Axivion is currently the only tool that can statically analyze CUDA source code while enforcing NVIDIA’s CUDA safety programming rules. This provides a unified analysis capability across:
Host-side C/C++ code interacting with CUDA APIs
Device-side CUDA kernels
Memory management and transfer logic
By integrating CUDA safety rules into one joint analysis pipeline, teams achieve:
Uniform quality standards across heterogeneous code
Early detection of GPU-specific defects
Reduced debugging and validation effort
This approach produces several concrete benefits:
Traceability: Every migration step is tied to architectural intent
Isolation: Changes are confined to well-defined components
Correctness: Continuous verification prevents structural and functional safety regressions
Safety: CUDA-specific risks are systematically mitigated
The result is not just a GPU-enabled system, but one that remains structurally sound and maintainable.
GPU migration is often framed as a performance optimization task. In practice, it is a system evolution problem. Treating it as such—by combining architecture recovery, verification, and safety rule enforcement—enables teams to scale migration efforts without losing control over system complexity.
This article was written in co-operation with Dr. Sebastian Krings.