microsoft/newtonsoft-json-migration
> Migrates .NET projects from Newtonsoft.Json to System.Text.Json. Use when user wants to replace Newtonsoft.Json, switch to System.Text.Json, migrate JSON library, or modernize JSON serialization.
npx skills add https://github.com/microsoft/upgrade-agent-plugins --skill newtonsoft-json-migration
Scan the solution to build a complete picture of Newtonsoft.Json usage. Capture findings in assessment.md.
Search all project files and package management files (Directory.Packages.props) for:
Newtonsoft.Json (direct package reference)Newtonsoft.Json.Bson, Newtonsoft.Json.Schema, or other Newtonsoft extension packagesSearch all code files across the solution for using Newtonsoft.Json (and variations like using Newtonsoft.Json.Linq). Record which files in which projects contain these usings — this gives a quick per-project file count that drives planning.
The patterns below help gauge complexity per project. You don't need to search for each one separately — note them as you encounter them during the usings scan or during execution:
| Pattern | What to Record |
|---------|---------------|
| JsonConvert.SerializeObject / DeserializeObject | Count and locations — most common migration target |
| JsonSerializer (Newtonsoft) usage | Direct serializer use, especially with custom settings |
| [JsonProperty], [JsonConverter], [JsonIgnore] | Attribute-heavy models — bulk replacement needed |
| Custom JsonConverter implementations | High complexity — System.Text.Json converters have different API surface |
| JObject, JArray, JToken manipulation | Needs JsonDocument/JsonElement or JsonNode replacement |
| JsonSerializerSettings configuration | Settings like NullValueHandling, ReferenceLoopHandling, ContractResolver |
| Public API types using Newtonsoft types | Downstream consumers affected — higher risk |
Flag these as higher complexity in the assessment:
JObject, JToken, or Newtonsoft-attributed types — downstream breaking changeJsonConverter<T> subclasses — API surface differs significantly between librariesJObject.Parse, LINQ-to-JSON — requires structural rewrite to JsonDocument or JsonNodeContractResolver, ReferenceLoopHandling, or PreserveReferencesHandling — some have no direct System.Text.Json equivalentCreate assessment.md in the workflow folder with this structure:
# Assessment: Newtonsoft.Json to System.Text.Json
## Affected Projects
| Project | Newtonsoft Packages | Key Patterns | Public API Exposure | Risk |
|---------|---------------------|-------------|---------------------|------|
| MyApp.Core | Newtonsoft.Json | JObject manipulation, custom converters | Yes — API returns JObject | High |
| MyApp.Web | Newtonsoft.Json | JsonConvert, [JsonProperty] | No | Low |
## Transitive Consumers
Projects that reference affected projects but don't directly use Newtonsoft:
- [list or "none"]
## Key Findings
- [Notable patterns, risks, or decisions needed]
Based on the assessment, create plan.md with tasks ordered bottom-up (leaf dependencies first, then consumers).
For each task include:
Projects exposing Newtonsoft types in public APIs should be migrated before their consumers. Projects that are transitive-only consumers still need a task if their code references types that will change.
Execute the plan task by task. For any task that involves migrating Newtonsoft.Json code or packages, apply the migrating-newtonsoft-to-system-text-json feature skill. It provides API mappings, package changes, code transformations, and validation steps.
After completing all tasks, do a final solution-wide search for any remaining Newtonsoft.Json references and fix stragglers.
Newtonsoft.Json namespace references in codeTake microsoft/newtonsoft-json-migration from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.