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: Record the current template shape

Use scaffolding-revit-projects to identify the current template short name and options. Record them with the installed template version and project or solution name.

Step 2: Generate an equivalent target reference

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

dotnet new install Nice3point.Revit.Templates
dotnet new  --name  --output  

Matching the name avoids namespace and generated-path noise. Matching options ensures every diff comes from the target template rather than a different project shape.

Step 3: Review the generated diff

Compare the reference directory with the current project or solution.

git diff --no-index --  

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 4: Apply the reviewed changes

Update each project only from the matching generated template type. Keep .addin, deployment, launch, GUIDs, and dynamic-loading configuration in the manifest-owning add-in or application project. Do not copy those settings into a module, benchmark, or test project.

Step 5: 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 instead of the target version | Install and generate the exact target version before comparing. | | Comparing different template options | Match every current option so the diff is meaningful. | | 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. |

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Nice3point
• Source: Nice3point/revit-skills
• License: MIT

Install and usage instructions live in the source repository linked above.