Isaac Sim 6.0 Migration Strategy

Use this page to plan a migration from Isaac Sim 5.x to Isaac Sim 6.0 before editing code. Isaac Sim 6.0 removes older compatibility shims, moves several runtime APIs to experimental packages, and deprecates some monolithic tools in favor of focused extensions or app-owned workflows.

Python Runtime

Isaac Sim 5.1 bundles Python 3.11.13. Isaac Sim 6.0 bundles Python 3.12.13. Rebuild the following against the 6.0 Python runtime:

• Project virtual environments

• Compiled wheels

• Native Python extensions

• ROS 2 Python packages

• Custom message workspaces

• Machine learning (ML) dependencies

Do not copy a 5.x site-packages directory into a 6.0 installation, even when imports appear to resolve.

Migration Order

Complete these steps in order:

1. Inventory your project.

   Run Project Migration Audit or an equivalent project-owned inventory. Search the following for deprecated packages and workflow patterns:

   • Extension manifests

   • App .kit files

   • Python imports

   • Saved Universal Scene Description (USD) Action Graphs

   • ROS workspaces

   • Generated assets

   • Benchmark scripts

   • Continuous integration (CI) smoke tests

2. Remove the old omni.isaac.* compatibility layer first.

   If the project still uses omni.isaac.* extension names, migrate those names with Renaming Extensions in Isaac Sim 4.5 before applying the 6.0 guides.

3. Migrate runtime APIs by workflow.

   Do not replace all imports mechanically. Validate the lifecycle of each workflow: stage creation, simulation step, rendering, graph execution, writer output, and asset save/load.

4. Open saved USD stages in Isaac Sim 6.0 and save migrated copies.

   The deprecation manager handles some Action Graph and node namespace migrations when the stage opens. Save the stage after migration so future runs do not depend on compatibility bridges.

5. Keep deprecated extensions enabled only as a short transition aid.

   A migrated project should not enable deprecated packages unless the remaining dependency is intentional, documented, and scheduled for removal.

Coverage Matrix

6.0 change area	Migration action	Validation target
Removed omni.isaac.* compatibility shims	Migrate extension dependencies and imports to isaacsim.* using Renaming Extensions in Isaac Sim 4.5.	App starts without omni.isaac.* extension names.
Project-wide migration inventory	Run Project Migration Audit and assign every required finding to a workflow owner before editing code.	Audit findings have owners and map to runtime validation tasks.
Core API, prim wrappers, and utilities	Use Core API to Core Experimental API and replace World-centric code with explicit stage, simulation, and rendering managers.	One reset, step, render, and callback cycle succeeds.
Camera, RTX, and physics sensors	Use the sensor migration guides in this section and move authoring to isaacsim.sensors.experimental.* APIs.	Sensor prims load, render or simulate, and publish expected data.
Sensor timing, external simulation time, and RTX Lidar assets	Use Sensor Timing and RTX Lidar Asset Migration to replace helper-node frame skipping with sensor tickRate and convert legacy Camera-prim RTX Lidar JSON assets.	Observed sensor cadence, timestamps, and converted OmniLidar assets match the project baseline.
ROS 2 OmniGraph publisher node inputs	Use ROS 2 OmniGraph Nodes and feed publisher nodes from dedicated source nodes.	Saved graphs load without deprecated prim-path inputs.
ROS 2 sensor helper and point-cloud graphs	Use ROS 2 Sensor Graph Migration for CameraInfo calibration, RTX helper scheduling, and PointCloud2 metadata flags.	ROS image, CameraInfo, Lidar, Radar, and PointCloud2 messages match the expected fields and cadence.
Isaac Sim ROS workspace package layout	Use ROS 2 Workspace Package Migration for the isaacsim to isaacsim_bringup rename and ament_python package layout.	colcon build and the project launch files pass.
ROS 2 URDFImportFromROS2Node command	Replace the deprecated Kit command with RobotDefinitionReader and URDFImporter.	Imported robot USDs load with the expected articulation and assets.
URDF, MJCF, exporter, and robot asset pipeline	Use URDF, MJCF, and Robot Asset Pipeline Changes for importer APIs, tri-state base type, ROS 2 robot descriptions, exporter checks, and Asset Transformer workflows.	Imported and exported robot assets preserve joints, drives, materials, references, and base behavior.
Robot asset paths and multiphysics variants	Use Robot Asset Path Migration to review /Isaac/Robots references and move to /Isaac/Robots_Multiphysics only when a catalog entry exists and validation status is acceptable.	Migrated robot paths load, reset or step, initialize controllers, and preserve the workflow’s expected prim, joint, sensor, and material assumptions.
Replicator domain randomization	Use Replicator Domain Randomization Extension and enable isaacsim.replicator.experimental.domain_randomization.	Randomization triggers and writer outputs still occur.
MobilityGen package and recordings	Use MobilityGen Package and Recordings and convert old state/common/*.npy recordings to *.npz.	Replayed recordings produce nonzero steps.
Manipulator and wheeled robot packages	Use Manipulator and Wheeled Robot Extension Split and split Python APIs, examples, and OmniGraph nodes into the new packages.	Robot commands and graph nodes execute during playback.
Robot motion generation	Use Robot Motion Generation APIs and move to the experimental motion-generation API plus cuMotion or PINK.	Known start and goal states still satisfy error and collision checks.
Extension Template Generator	Use Extension Template Generator to CLI Templates and generate new extensions with ./repo.sh template new.	Generated extension builds and its startup test passes.
Robot Wizard and mesh merge	Use Robot Wizard and Mesh Merge Tool Migration; split the old wizard workflow across importers, robot setup tools, XRDF editor, Robot Schema, Asset Transformer, and Scene Optimizer.	Saved robot assets reload with valid schema, joints, drives, and mesh optimization.
isaacsim.replicator.agent 0.x	Use Replicator Agent (IRA).	Existing actor SDG configs load through the 1.x schema.
Surface gripper compiled-binding imports	Use Surface Gripper Bindings; update deep imports of _surface_gripper to the bindings submodule or the package-root re-export.	Migrated imports resolve and the gripper interface acquires.
Benchmark services	Use Benchmark Services Migration and replace constructor flags such as gpu_frametime=True with explicit recorder lists.	Benchmark output still contains every KPI consumed by dashboards and CI.
isaacsim.asset.browser	Use omni.simready.content.browser and update app dependencies.	Content Browser opens the expected SimReady folders.
omni.isaac.ml_archive	Install PyTorch and related ML dependencies directly, or explicitly enable the deprecated extension only for a legacy workflow.	ML imports resolve from the project environment.
Removed app selector, benchmark examples, Scene Blox, asset browser, and ML archive	Use Removed Tools and Replacements. Remove no-replacement dependencies, migrate asset browser usage to omni.simready.content.browser, and install ML dependencies directly.	App manifests no longer enable removed extensions, and startup logs have no missing-extension errors.

Validation Plan

Use a layered validation pass after each migrated workflow:

• Static inventory: search manifests, imports, launch files, and saved graph assets for deprecated extension names.

• Startup smoke test: start the app or extension with the migrated dependency set and fail on missing-extension, missing-node, or import errors.

• Runtime smoke test: run at least one reset, one simulation step, and any workflow-specific output path such as render products, ROS messages, writers, robot commands, or saved USD assets.

• Data compatibility test: replay or convert representative saved artifacts, including MobilityGen recordings, USD Action Graphs, robot USDs, and ROS launch files.

• Regression comparison: compare a small known scene against the 5.x baseline using the project metric that matters: joint error, transform count, sensor frames, annotations, writer rows, or launch success.

Do not consider a migration complete because imports resolve. Many 6.0 changes affect lifecycle ownership, graph data flow, USD authoring, and package layout, so the migrated path must run through the same state transitions used by the customer workflow.