Helping developers migrate embedded codebases between Arm SoCs (System on a Chip), AI can transform what has traditionally been complex work. Embedded software development has always been about making the best possible use of limited hardware. Memory, compute power, and energy are constrained, and developers must constantly optimize to reach the required performance and reliability. In these situations, AI helps navigate the jungle of possible optimizations when migrating a codebase.

Moving from one SoC to another, teams usually face more complex challenges than just recompiling the code. Migrations can be driven by a new chip generation, changes in company strategy, supply-chain decisions, or the desire to reuse an existing code base for new products. Each move brings differences in architecture, instruction sets, peripherals, tooling, and compliance requirements.

This post presents a new Kiro Power called the Arm SoC Migration Power, helping developers migrate codebases between Arm SoCs. The Kiro Arm SoC Migration Power is released as a collaboration of Arm and AWS.

Kiro is an AI-powered Integrated Development Environment (IDE) from AWS. It recently added support for so-called Powers. Powers provide domain-specific guidance for recurring engineering challenges. Rather than automating changes or generating code blindly, a Power analyzes context, highlights constraints, and helps engineers reason about complex questions.

Kiro uses a specification-driven approach to guide its AI agents. Instead of ad-hoc prompting, developers describe what they want to build and the agent works against that definition.

A Kiro specification starts as a simple requirement. Developers type a short sentence describing a feature. Kiro then expands it into a structured specification written in Markdown. The specification lives in a .md file inside a specs/ folder in the project.

Each specification contains three sections that Kiro generates in sequence: Requirements break the feature down into user stories with clear acceptance criteria. Design lays out the technical approach, which files to change, what data structures to use, how components interact. Tasks turn the design into a step-by-step implementation checklist the agent can execute.

Here is a short example of what a requirements section looks like in a Kiro specification, written in Markdown:

# Spec: Add to Cart

## Requirements

### User Stories

#### Story 1: Add item to cart
As a shopper, I want to add an item to my cart so that I can purchase it later.

**Acceptance Criteria:**
- Given I am on a product page, when I click "Add to Cart", then the item appears in my cart.
- Given the item is out of stock, when I click "Add to Cart", then I see an error message.
- Given I already have the item in my cart, when I click "Add to Cart", then the quantity increases by one.

Without this structure, many teams practice what is often called vibe coding. Progress looks fast at the beginning, but eventually the system degrades, produces inconsistent results, or appears stuck. Developers then try to reformulate prompts, retry, or restart from scratch, losing time. By anchoring the work in specifications, Kiro reduces this trial-and-error cycle and keeps migrations aligned with the technical goals.

The remainder of this blog post is structured as follows. The next section presents an example from the automotive industry. The example describes the importance of the new Arm SoC Migration Kiro Power for the automotive industry. The following section shows the Arm SoC Migration Kiro Power. It presents multiple application examples and goes in detail about what developers can expect using the Arm SoC Migration Power. The last Section summarizes this blog post.

Example: Why the Arm SoC Migration Kiro Power is relevant in the automotive industry

Parallelizing software development and hardware development when starting a new ECU (Electronic Control Unit) project, automotive companies manage to bring down development times from up to five years or more to a target of 18 months or less. Automotive companies create and use virtual versions of their ECUs on AWS to enable early integration and testing. Later in the project, development teams face the challenge of moving from those early environments to production hardware without losing functional behavior, performance characteristics, or safety properties along the way.

Changing from one microcontroller to another, or from a virtualized version of ECU hardware to the target hardware, embedded software development teams aim to reuse as much of their existing code base as possible. One major requirement is that the existing code running on a new platform should perform equally well or even better.

Kiro, implementing spec-driven development, guides developers to create a specification and technical design that is understandable by AI coding agents. The goal is to let humans describe the important decisions for the development task at hand and let the AI agent add and implement the necessary technical details to arrive at the desired implementation.

In practice, most embedded teams move through three stages during development.

Automotive software development stage 1

In the first stage, teams face the non-availability of production ECU hardware. With Amazon EC2 instances powered by AWS Graviton processors, teams can start immediately on Arm-based infrastructure that aligns well with automotive hardware where Arm CPUs are widely used.

Using Graviton virtual machines on AWS, development teams can build and test core application logic, validate algorithms, and run continuous integration pipelines without waiting for physical hardware. This approach is also useful for distributed teams, where consistent, reproducible development environments are difficult to maintain across local setups.

Automotive software development stage 2

In the second stage, when teams prototype embedded workloads on low-cost Arm-based hardware, they face the first point where they need to migrate the codebase. In this phase teams typically focus on the fundamental electrical and protocol interfaces that later exist on the production ECU as well. Even if the target will ultimately run on an automotive SoC, validating these interactions on a developer platform can eliminate a significant portion of integration risk long before the target-hardware boards arrive.

At this stage, software maturity is driven less by peak compute performance and more by determinism at the boundaries: are signals arriving, are protocols interpreted correctly, and does the system react within the expected time budgets. By exercising real in-vehicle networks, real wires, and real interrupt paths, engineers move from functional correctness toward behavioral confidence, which is what ultimately determines whether bring-up on first hardware becomes routine or escalates into a program delay.

Automotive software development stage 3

The final stage is migration to production hardware, integrating automotive SoCs like the NXP i.MX 8M Plus. By this point, the goal is no longer basic functionality. It is ensuring that performance, timing and safety behavior remain consistent under real automotive constraints.

Teams that treat this step as a simple port often face unforeseen challenges. Teams that plan for it as a managed transition tend to reach production with fewer surprises and clearer understanding of residual risk.

Figure 1, below, shows how a code base is modified to match the specific characteristics of each Arm CPU when going through all stages of automotive software development.

Figure 1: Embedded Software Development Process

Software development started at an Amazon EC2 instance on the far left. The EC2 instance in use is a C7G instance. C7G instances are equipped with a Graviton3 CPU implementing the ARMv8.4-A instruction set. When migrating to low-cost ARM hardware for sensor integration, developers often need to target a baseline instruction set. This means using only the CPU features that work across all ARM processor versions in their deployment environment. That is because the Raspberry Pi 5 is equipped with a CPU with a lower version of the Arm instruction set, which is v8.2. Moving to the target hardware usually requires dealing with another step back in terms of instruction set version.

How the Arm SoC Migration Power for Kiro supports controlled transitions

A large benefit of using Arm-based platforms is the environmental parity from cloud to edge devices, enabling code portability between systems. However, one of the most common misconceptions in embedded development is that code that easily compiles and runs on multiple Arm platforms will behave equivalently across them. Differences at the SoC level can have significant effects, especially in safety-relevant systems.

Across environments such as AWS Graviton, Raspberry Pi, and automotive ECUs, teams encounter differences in CPU microarchitecture, memory hierarchy, integrated accelerators, and power-management domains. In practice, memory behavior and power-state transitions are among the most underestimated sources of late-stage issues. Similarly, SIMD-heavy code that performs well on one Arm core may behave very differently on another due to differences in execution pipelines or available instruction sets. Code that performs well on server-class CPUs can exhibit timing variability or performance degradation on embedded automotive platforms with tighter constraints.

These differences are manageable but only if they are made visible early.

The Arm SoC Migration Power in the Kiro IDE is designed to make architectural differences explicit during each transition, rather than allowing them to surface late through regressions or field issues.

Instead of treating migration as an ad-hoc activity, the Arm SoC Migration Power structures it as a guided workflow covering discovery, analysis, planning, implementation, and validation. While all phases matter, teams often underestimate discovery. Incorrect assumptions about the source platform, particularly around SIMD usage, cache behavior, or execution model, tend to propagate downstream and become expensive to correct later.

A key design principle of the Arm SoC Migration Power is that it does not automate porting decisions or replace engineering judgment. Instead, it highlights the architectural differences, constraints, and trade-offs that teams need to consider when migrating from one SoC to another.

By making changes in CPU behavior, SIMD support, memory hierarchy, power management, and accelerator availability explicit, it helps engineers reason about potential impacts early and plan migrations deliberately rather than discovering issues late through testing or system integration failures.

By formalizing transitions between virtual environments, prototyping platforms, and production ECUs, teams can start development earlier. This may help reduce late-stage surprises, and maintain cleaner platform abstractions across the lifecycle.

Most importantly, migration stops being a last-minute fire drill and becomes a planned engineering activity.

The Arm SoC Migration Power also includes the capabilities of the Arm MCP (Model Context Protocol) Server. The Arm MCP Server contains tools and curated knowledge to make software development easier on Arm. This includes hundreds of Arm Learning Paths, reproducible tutorials with code examples to accomplish various tasks across Arm-based devices.

This means you can directly chat with best-practice documentation without leaving your Kiro environment. From Prototyping safety-critical isolation for autonomous driving to running a local LLM chatbot on a Raspberry Pi, you can accelerate development with trusted guidance tailored to your Arm SoC target. For more details see the Arm MCP Server product page.

Summary and Outlook

As software-defined vehicle (SDV) architectures evolve, hardware transitions are becoming more frequent rather than less. OEMs are moving away from long-lived, function-specific ECUs toward centralized and zonal compute platforms that evolve across vehicle generations, trims, and even model years. At the same time, SoC roadmaps are advancing faster than traditional vehicle lifecycles, introducing new CPU cores, accelerators, and memory architectures on a shorter cadence.

This combination means software teams must adapt to hardware change more often, not just between vehicle generations, but within a single platform family. As compute is centralized and accelerators are shared across domains, realistic hardware environments increasingly become the only way to validate system-level behavior, timing interactions, and resource contention.

The Arm SoC Migration Power in the Kiro IDE is designed to support that shift, and help teams move from virtual ECUs to production hardware with fewer surprises, clearer intent, and greater confidence. Download Kiro today and follow the Arm SoC Migration Learning Path.