Why Jetson Xavier Is Being Phased Out – And How to Choose Your Next Platform

NVIDIA’s Jetson ecosystem has moved through several major generations: Jetson Nano, TX2, Xavier, Orin, and now Thor. For companies building embedded AI products, that sequence is not just a product roadmap. Each generation reshapes software support, supply chain planning, thermal design, and long-term product viability.

Why Xavier Can No Longer Be the Default

The Xavier family is no longer just aging, it is actively being wound down, and the timeline has accelerated sharply due to a supply chain problem that was not on most teams’ radars. If you are still designing around Xavier, the window to act is closing faster than most teams realize.

Xavier modules depend on LPDDR4 memory, a technology that is no longer the focus of the industry. As supply tightened across the DRAM market, NVIDIA moved the TX2 NX, TX2i, AGX Xavier, and Xavier NX modules to Non-Cancelable, Non-Returnable (NCNR) status. The key dates are blunt: NVIDIA has communicated that July 15, 2026 was the final forecast and purchase-order deadline for the affected LPDDR4-based Jetson modules. Everything placed by that date is expected to ship no later than July 15, 2027 on a non-cancellable, non-returnable basis. Some distributors and ecosystem partners may enforce earlier last-time-buy dates, but for NVIDIA’s own published timeline, July 15, 2026 was the critical deadline. For teams that have not yet acted, the procurement window is in its final stage.

There is also a software angle that matters independently of supply. JetPack 4, the last version supporting TX2 NX and Jetson Nano, was declared end-of-life in November 2024. Those platforms share no baseline with any current Orin platform, meaning migration requires a full software stack transition. Jetson AGX Xavier and Jetson Xavier NX have a somewhat better position: both remain on the JetPack 5 branch, which also supports Jetson Orin. As of JetPack 5.1.6, NVIDIA supports Jetson AGX Xavier, Xavier NX, AGX Orin, Orin NX, and Orin Nano production modules on the same JetPack 5.x software family, with Ubuntu 20.04 and CUDA 11.4.19. That gives Xavier-to-Orin teams a less complicated migration path rather than an immediate full software rewrite.

One episode in particular illustrates the lifecycle risk that deserves attention: Component supply constraints forced NVIDIA to pull in the Jetson AGX Xavier Industrial EOL from 2031 to 2027, cutting four years off planned production runways. It is a stark reminder that even industrial roadmaps are subject to supply chain realities. For teams now choosing between Orin and Thor, system architectures need to streamline BSP porting and decouple custom I/O early so you aren’t caught unprepared by upstream silicon changes.

Besides these considerations, there is also a strong technical reason to migrate: Jetson AGX Orin delivers AI performance up to 275 TOPS with up to 64 GB of memory, compared to 30 TOPS with up to 32 GB for AGX Xavier. Xavier is not just aging out operationally, it is increasingly outclassed for modern AI workloads.

What the Numbers Say About the Xavier-to-Orin/Thor Migration

Specification	Jetson AGX Xavier	Jetson AGX Orin	Jetson AGX Thor / T5000
AI Performance	32 TOPS	275 TOPS	2070 TFLOPS (FP4-sparse)
GPU	512-core NVIDIA Volta architecture GPU with 64 Tensor Cores	2048-core NVIDIA Ampere architecture GPU with 64 Tensor Cores	2560-core NVIDIA Blackwell architecture GPU with fifth-gen Tensor Cores Multi-Instance GPU (MIG) with 10 TPCs
CPU	8-core NVIDIA Carmel Arm®v8.2 64-bit CPU 8MB L2 + 4MB L3	12-core Arm® Cortex®-A78AE v8.2 64-bit CPU 3 MB L2 + 6 MB L3	14-core Arm® Neoverse®-V3AE 64-bit CPU 1 MB L2 Cache per core 16 MB Shared System L3 Cache
DL Accelerator	2x NVDLA	2x NVDLA v2	–
Vision Accelerator	2x PVA	1x PVA v2	1x PVA v3
Memory	64GB 256-bit LPDDR4x 136.5GB/s	64 GB 256-bit LPDDR5 204.8 GB/s	128 GB 256-bit LPDDR5X 273 GB/s
Storage	32GB eMMC 5.1	64 GB eMMC 5.1	Supports NVMe through PCIe Supports SSD through USB3.2
Video Encode	4x 4K60 (H.265) 8x 4K30 (H.265) 16x 1080p60 (H.265) 32x 1080p30 (H.265)	2x 4K60 (H.265) 4x 4K30 (H.265) 8x 1080p60 (H.265) 16x 1080p30 (H.265)	2X NVENCODE
Video Decode	2x 8K30 (H.265) 6x 4K60 (H.265) 12x 4K30 (H.265) 26x 1080p60 (H.265) 52x 1080p30 (H.265)	1x 8K30 (H.265) 3x 4K60 (H.265) 7x 4K30 (H.265) 11x 1080p60 (H.265) 22x 1080p30 (H.265)	2X NVENCODE
CSI Camera	Up to 6 cameras (36 via virtual channels) 16 lanes MIPI CSI-2 | 8 lanes SLVS-EC D-PHY 1.2 (up to 40 Gbps) C-PHY 1.1 (up to 62 Gbps)	Up to 6 cameras (16 via virtual channels) 16 lanes MIPI CSI-2 D-PHY 2.1 (up to 40Gbps) | C-PHY 2.0 (up to 164Gbps)	Up to 20 cameras via HSB Up to 6 cameras through 16x lanes MIPI CSI-2 Up to 32 cameras using Virtual Channels C-PHY 2.1 (10.25 Gbps) D-PHY 2.1 (40 Gbps)
PCIe	1 x8 + 1 x4 + 1 x2 + 2 x1 (PCIe Gen4, Root Port & Endpoint)	Up to 2 x8 + 1 x4 + 2 x1 (PCIe Gen4, Root Port, & Endpoint)	Up to Gen5 (x8 lanes) Root port only-C1 (x1) and C3 (x2) Root Point or Endpoint-C2 (x1), C4 (x8), and C5 (x4)
USB	3x USB 3.2 Gen2 (10 Gbps) 4x USB 2.0	3x USB 3.2 Gen2 (10 Gbps) 4x USB 2.0	xHCI host controller with integrated PHY (up to) 3x USB 3.2 4x USB 2.0
Networking	1x GbE	1x GbE 1x 10GbE	4x 25GbE
Display	3 multi-mode DP 1.4/eDP 1.4/HDMI 2.0	1x 8K60 multi-mode DP 1.4a (+MST)/eDP 1.4a/HDMI 2.1	4x shared HDMI2.1 VESA DisplayPort 1.4a-HBR3, MST
Power	10W – 30W	15 W-60 W	40 W-130 W
JetPack	JetPack 4.x / 5.x	JetPack 5.x / 6.x / 7.2	JetPack 7.x
CUDA version	CUDA 10.x / 11.4.19	CUDA 11.4.19 / 12.x / 13.x	CUDA 13.x

The NVIDIA Orin performs up to 8 times better than Xavier for simultaneously handling multiple concurrent pipelines. That is the relevant metric for multi-camera and multi-model edge deployments. For raw AI compute, the comparison is 275 TOPS versus 32 TOPS at the top SKU. Real-world benchmarking at the time of Orin’s launch showed improvements of up to 3.3x over AGX Xavier using software available at that time, with further gains expected through ongoing software optimization.

On the silicon side, the generational jump is significant across every subsystem. The AGX Orin replaces NVIDIA’s Carmel CPU clusters with 12 Arm Cortex-A78AE cores, delivering 1.7x the CPU performance compared to the 8-core Carmel on AGX Xavier. The GPU moves from Volta to Ampere, introducing third-generation Tensor Cores, TF32 precision, and sparsity support that doubles Tensor Core throughput over the prior generation. Memory bandwidth is 1.4x higher, with a move from LPDDR4x to LPDDR5. These are not incremental improvements, they are a full architectural generation.

The software transition story is better than it first appears for AGX Xavier and Xavier NX users specifically. Jetson AGX Orin and AGX Xavier share JetPack 5.0 / L4T 34.1 as a common baseline. That means you can bring up your system on Jetson AGX Orin without immediately overhauling your software stack, swap the module, validate the hardware, then move to JetPack 6 on your own timeline. It is a staged migration rather than a cold-start rewrite. The same logic applies to Xavier NX to Orin NX: both share a JetPack 5.1 baseline.

Ecosystem partners have also done substantial work to preserve carrier board investment. For NVIDIA Jetson AGX Xavier users on compatible carrier boards, there are multiple Jetson AGX Orin upgrade options depending on footprint and I/O requirements. Rugged and defense users on specialized systems have a direct path to next-generation chassis platforms, maintaining MIL-STD-810H and DO-160H compliance. For teams in harsh or extended industrial environments, the Jetson AGX Orin Industrial is the appropriate target rather than standard Orin NX modules.

Orin itself is also still getting stronger without the need to change the hardware. JetPack 7.2 introduces a Super Mode for the AGX Orin 32GB module, raising its performance from 200 TOPS to 241 TOPS, an increase of over 20%  at a power envelope of 60W. JetPack 7.2 also brings CUDA 13 to Jetson Orin, meaning existing Orin deployments gain access to the latest compute stack. Orin is not a platform being left behind while the industry moves to Thor; it is actively being extended.

Thor – The Forward-Looking Target

Jetson Thor is powered by NVIDIA’s Blackwell GPU architecture and represents a full generational leap rather than an incremental upgrade. The top-line numbers: up to 2,070 FP4 TFLOPS of AI compute, 128 GB of LPDDR5X memory, and a power envelope of 40-130W, claiming 7.5x the AI performance and 3.5x the energy efficiency of AGX Orin.

The 128 GB memory specification is particularly significant. It makes larger and more concurrent foundation-model workloads practical at the edge, with fewer memory constraints than Orin. Orin can run some multi-billion-parameter models when they are optimized, quantized, or carefully sized, but Thor gives teams far more headroom for large vision-language models, LLMs, agentic AI, and multi-model robotics workloads. That is the capability unlock that makes Thor relevant not just as a faster Orin, but as a qualitatively different platform for a new class of applications: agentic AI at the edge, real-time inference on large vision-language models, and generalist robotics that can adapt to new tasks without being reprogrammed.

Thor runs JetPack 7 on Ubuntu 24.04 LTS with Linux Kernel 6.8. JetPack 7.0 shipped with CUDA 13.0 and TensorRT 10.13, while JetPack 7.2 moves the stack to CUDA 13.2.1 and TensorRT 10.16.2. If you are naming a specific release, use the exact version; otherwise, refer to CUDA 13.x and TensorRT 10.x. This is a full-generation software stack jump, and the break is real. Thor shares its JetPack software baseline with the Orin platform starting from JetPack 7.2. Consequently, migration from Xavier to Thor requires a clean-slate software transition.

JetPack 7 also aligns Jetson software with the Server Base System Architecture (SBSA), positioning Jetson Thor alongside industry-standard Arm server design. SBSA standardizes hardware and firmware interfaces, which means stronger OS support, simpler software portability, and smoother integration with enterprise tooling. CUDA 13.0 is now unified across all Arm targets, which matters for teams whose development workflow spans data center and edge.

Thor became generally available in August 2025. NVIDIA’s launch announcement listed Agility Robotics, Amazon Robotics, Boston Dynamics, Caterpillar, Figure, Hexagon, Medtronic, and Meta among early Jetson Thor adopters, with 1X, John Deere, OpenAI, and Physical Intelligence evaluating the platform.

That said, the ecosystem is still maturing. Documentation for container support is fragmented, and teams using runtimes other than Docker need to build certain dependencies from source. Runtime maturity should be validated against the exact JetPack, container, and inference framework versions being used. JetPack 7.0 introduced support for AI serving frameworks such as vLLM and SGLang, but container availability and FP4 workflows have evolved across JetPack releases. Teams using Kubernetes, systemd containers, or non-Docker workflows should validate their deployment stack early.These are solvable problems, but they represent real friction for teams with existing Kubernetes or systemd container workflows.

The Memory Market Problem That Runs Through All of This

The supply dynamics behind the Xavier situation help explain why it deteriorated faster than most teams expected, and why they matter for future platform selection.

The TX2 and Xavier families depended on LPDDR4 memory, which is no longer the volume focus of the semiconductor industry. When supply tightened, driven partly by overwhelming demand for newer memory types from AI data centers, maintaining long lifecycle guarantees for aging embedded platforms became untenable. NCNR status was the earliest visible signal; accelerated EOL followed.

Current Jetson platforms are better aligned with newer memory technologies than Xavier-era modules: Orin uses LPDDR5, while Thor uses LPDDR5X. That positions them better than LPDDR4-based platforms, but it does not eliminate supply-chain risk. AI data center demand continues to put pressure on the broader memory market, and industry analysis expects supply-demand imbalance to persist into or beyond 2027 in key segments. This is a background risk worth tracking for all embedded AI platform planning.

A Decision Framework for Engineering Teams

If you are currently on Xavier and have not yet secured a last-time forecast or purchase order, the procurement window is at its final stage. NVIDIA’s published deadline is July 15, 2026, after which new orders are not expected to be accepted. After that deadline, the focus should shift entirely to validating an Orin-based replacement and planning the software transition.

If you are migrating an existing Xavier deployment to a near-term production platform, Orin is the correct target. The shared JetPack 5 baseline makes this a staged transition rather than a rewrite. Form factor and carrier board continuity is well-supported across the ecosystem for most common Xavier configurations. For teams that need custom carrier board design or system architecture support for that transition, this is exactly the kind of program Tauro Technologies works on,  from PCB design through manufacturing readiness.

If you are in a harsh or extended industrial environment, the Jetson AGX Orin Industrial is the appropriate migration target. The lifecycle reduction on AGX Xavier Industrial from 2031 to 2027 should inform how you weight lifecycle track record in future platform selection, alongside compute specifications. Ruggedization and reliability engineering, thermal re-qualification, and shock and vibration testing are not optional steps in these environments,  they are the difference between a migration that holds in the field and one that does not.

If you are starting a new design today and your application involves foundation models, multi-sensor fusion for humanoid robotics, or inference on large vision-language models, Thor is worth serious evaluation despite the software stack break. Tauro Technologies is already building production hardware around NVIDIA’s Orin and Thor ecosystem. The TT300 family spans Orin- and Thor-based edge AI platforms, while TT310 and TT315 are Thor-focused designs built for physical AI workloads rather than adapted from earlier-generation products. If you want to go deeper on what production-ready Thor deployment looks like in practice, we covered it in detail in How to Scale Physical AI: A Guide to Production-Ready Platforms.

For all teams, the LPDDR4 supply story is a useful reminder that embedded AI platform decisions are increasingly tied to DRAM market dynamics. Platforms built on current volume memory technology are structurally better positioned than those on declining ones, and that criterion belongs in your platform evaluation checklist alongside TOPS, power envelope, and software support lifetime.

Migration Is an Engineering Problem, Not Just a Procurement One

Understanding the migration path and executing it are two different things. The hardware decision is only the beginning, real transitions involve PCB redesigns, software stack changes, thermal re-qualification, and in many cases a full system architecture review. Teams that treat migration as a module swap tend to discover the hard problems late, during DVT or in the field.

The work typically spans several disciplines at once: electrical engineering, PCB design for the carrier board, embedded software and system architecture decisions that determine whether Orin or Thor is actually the right fit, ruggedization and reliability engineering for anything leaving a controlled environment, and manufacturing readiness support to make sure the hardware you validate is the hardware you ship.

Tauro Technologies offers engineering services across all of these areas, specifically for teams building on Orin and Thor. If you are scoping a migration or starting a new design on either platform, get in touch. Let’s talk through your program.