Migrate applications between Arm platforms using Kiro Arm SoC Migration Power
Introduction
Install Arm SoC Migration Power
Develop on source platform
Migrate using Arm SoC Migration Power
Validate migration with testing
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

About this Learning Path

Skill level:  Advanced
Reading time:  1 hr
Last updated:  29 Jun 2026
Skill level:
  Advanced
Reading time:
  1 hr
Last updated:
  29 Jun 2026
Author:Daniel Schleicher
Arm IP:Neoverse Cortex-A
Tags: Performance and Architecture AWS Microsoft Azure Google Cloud Oracle Linux Kiro AWS EC2 GCC C CMake
Author:
  • Daniel Schleicher
Arm IP:
Neoverse Cortex-A
Tags:
Performance and Architecture AWS Microsoft Azure Google Cloud Oracle Linux Kiro AWS EC2 GCC C CMake

Who is this for?

This is an advanced topic for experienced developers who need to migrate applications between Arm-based platforms using AI-assisted tooling. You will work through a structured, repeatable migration workflow using Kiro Arm SoC Migration Power, moving an application from AWS Graviton3 (Neoverse) to Raspberry Pi 5 (Cortex-A). The techniques apply broadly to cloud-to-edge and cross-architecture migrations across the Arm ecosystem.

What will you learn?

Upon completion of this Learning Path, you will be able to:

  • Install and configure Kiro Arm SoC Migration Power
  • Apply a structured migration workflow across Arm platforms
  • Identify platform-specific and hardware-dependent code using AI-guided analysis
  • Implement hardware abstraction layers to isolate platform-specific dependencies
  • Validate and verify the migrated application using automated analysis

Prerequisites

Before starting, you will need the following:

  • Access to both source and target Arm platforms (for example, AWS Graviton3 and Raspberry Pi 5)
  • Working knowledge of C programming
  • Familiarity with Linux development environments and basic embedded or cloud deployment concepts
  • Experience building applications with GCC and CMake

Summary

AI-assisted

This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
You’ll migrate a C application between Arm platforms using Kiro’s Arm SoC Migration Power. First, you’ll install Kiro, enable the Migration Power, and run the Arm MCP server as a containerized backend. Then, you’ll build and validate the sensor-monitor application on an AWS Graviton3 source instance. The workflow proceeds through discovery, architecture analysis, abstraction design, and platform-specific implementation to separate hardware-dependent code behind a clear interface. You’ll then build the migrated code for the target, such as Raspberry Pi 5, and validate it using the Power’s testing recommendations to check functional behavior, platform compatibility, hardware interactions, and performance characteristics against the baseline.

Frequently asked questions

AI-assisted

These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
Where should Kiro and the Arm MCP server run during setup?
Kiro runs locally on your development machine. The Migration Power uses the Arm MCP server deployed as a containerized backend using Docker, started as described in the setup step so Kiro can connect to it.
Where do I open and build the `sensor-monitor` application before migrating?
Open and inspect the project locally in Kiro, then build and validate it on the AWS Graviton3 source instance. A successful baseline build and run on Graviton3 provides the reference behavior for migration.
How do I know the discovery phase has identified hardware-dependent code?
Use the Migration Power’s AI-guided analysis to review findings for platform-specific or hardware-dependent code paths. The analysis highlights areas to isolate behind an abstraction before porting.
What should the hardware abstraction layer include for this migration?
Define clear interfaces for hardware interactions and move platform-specific logic behind those interfaces. Provide target-specific implementations and use the existing build system to select the appropriate implementation per platform.
What results indicate the migration is validated on both platforms?
Both source and target builds should complete without platform-specific errors, and the application should pass functional checks and hardware interaction tests. Use the Power’s testing recommendations to confirm platform compatibility and compare performance characteristics against the source baseline.
Next