Importing dataset with references and cross-project image asset errors
You've run into a known limitation with Sanity's dataset import/export when moving content between different projects (as opposed to between datasets within the same project). The error you're seeing is expected behavior, and your workaround with weak references shows you understand the core issue.
The Problem with Cross-Project Imports
When you export a dataset using sanity dataset export, the resulting .ndjson file (or the NDJSON inside the .tar.gz) contains asset references that include the original project ID. Assets in Sanity are fundamentally tied to the project they were created in, so when you try to import them into a different project, Sanity correctly rejects them because the asset documents reference a project ID that doesn't match your target.
The --allow-assets-in-different-dataset flag exists in the CLI but is explicitly marked as "rarely used" and "should generally not be used" - it's there for very specific edge cases, not as a standard solution.
Better Solutions
1. Use the Cross Dataset Duplicator Plugin (Recommended)
The Cross Dataset Duplicator plugin was specifically built to handle migrating documents and assets between different Sanity projects and datasets. It provides a GUI-based approach from within Studio and handles the complexity of asset migration for you.
Install it with:
npm i @sanity/cross-dataset-duplicatorThis is the most straightforward solution for your use case and handles both documents and assets properly.
2. Re-upload Assets to the Target Project
If you want to stick with CLI-based approaches, you'll need to:
- Export your documents (which you've done)
- Download the actual asset files from your production project
- Upload those asset files to your development project using the Assets HTTP API or a script with the Sanity client
- Update the asset references in your NDJSON to point to the new asset IDs in the development project
- Import the updated NDJSON to your development dataset
This is more complex but gives you full control over the process.
3. For Same-Project, Different-Dataset Moves
If you're moving content between datasets within the same project (like production β development datasets in the same project), sanity dataset export and sanity dataset import should work correctly with assets included, since the assets remain in the same project.
About Your Strong References Issue
Your workaround of converting strong to weak references suggests you might have been importing documents in the wrong order. When using sanity dataset import with a proper .tar.gz export (not just raw NDJSON), the import process should handle reference ordering automatically. However, if you're importing just NDJSON files selectively, you need to ensure referenced documents exist before importing documents that reference them (pages before routes, assets before pages, etc.).
The dataset export documentation confirms that proper exports maintain referential integrity, but this only applies when moving within the same project or when using tools designed for cross-project migration like the Cross Dataset Duplicator.
Show original thread4 replies
Sanity β Build the way you think, not the way your CMS thinks
Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.