# Revit Template Migration

> Upgrade a Nice3point.Revit.Templates project or solution to the latest template or SDK version. USE FOR: moving a scaffolded add-in, module, benchmark, test project, or solution to a newer template or SDK version, or adding template options to an existing scaffold. DO NOT USE FOR: creating a brand-new project (use scaffolding-revit-projects), or changing only the supported Revit-year matrix (use revit-multi-version-configuration).

- Skill: `nice3point/revit-template-migration` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nice3point/revit-template-migration`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nice3point/revit-template-migration/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: nice3point (https://skillmd.com/u/nice3point)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nice3point/revit-template-migration

---


# Revit Template Migration

The dotnet template engine has no in-place upgrader.
Generate an equivalent project from the target template version, then use the diff between that generated project and the current project as the migration plan.
The generated output is the source of truth for the selected template version and options.

## When to use

- Upgrading a scaffolded add-in, module, benchmark, test project, or solution to a newer template or SDK version.
- Adding a template option such as a bundle, installer, tests, or CI to an existing scaffold.

## When not to use

- Starting a new project from scratch — that is `scaffolding-revit-projects`.
- Adding or removing a supported Revit year within an existing project — that is `revit-multi-version-configuration`.

## Workflow

### Step 1: Generate a target reference

Install a new templates version.
Create the same template type in an empty temporary directory, with the name and options the current project carries.

```shell
dotnet new install Nice3point.Revit.Templates
dotnet new <template-short-name> --help
dotnet new <template-short-name> --name <ProjectName> --output <reference-directory> <options>
```

Match the project/solution name.
A different name shifts namespaces and generated paths across the diff.

### Step 2: Review the generated diff

Compare the reference directory with the current project or solution.

```shell
git diff --no-index -- <current-directory> <reference-directory>
```

Treat every difference as a review item.
Take template-generated infrastructure and configuration changes that the current project needs.
Keep project identity, business logic, and deliberate product-specific customization unless the target template requires a compatible rewrite.

### Step 3: Apply the reviewed changes

Update each project only from the matching generated template type.
Keep `.addin`, GUIDs, deployment logic and dynamic-loading configuration in the original project.

### Step 4: Verify

Build every declared `Debug.RNN` and `Release.RNN` configuration.
Run every generated pipeline path selected by the project: tests, installer, bundle, or release preparation.

## Validation

- [ ] The reference uses the exact target template version, short name, name, and options.
- [ ] The generated reference was compared with the current project or solution before changes were applied.
- [ ] Only reviewed template changes were transferred.
- [ ] Project identity and business logic were preserved.
- [ ] Every declared configuration and selected output path succeeds.

## Common Pitfalls

| Pitfall                                                         | Correct approach                                                       |
|-----------------------------------------------------------------|------------------------------------------------------------------------|
| Generating the latest template when the target version is older | Install and generate the exact target version before comparing.        |
| Comparing different template options                            | Match every current option for a meaningful diff.                      |
| Copying a generated tree over the existing project              | Transfer reviewed changes selectively and preserve project-owned code. |
| Applying an application configuration to a module               | Compare each project with its own template type.                       |