Skip to content

After you Upgrade

This section includes various things to consider after you have successfully upgraded to Nautobot 2.0.

Review any Cleanup or VRF Namespaces

This may also apply to any "VRF Namespace" objects that were created, depending on your requirements on maintaining duplicate Prefix/IPAddress objects.

A priority of the upgrade process is to assert that no data will be lost. Due to the introduction of strict uniqueness constraints to disallow duplicate Prefix, IPAddress, and VRF objects within the same Namespace, depending on the nature of your data, you may have numerous "VRF" or "Cleanup" Namespaces that were automatically created by the upgrade process as described in the previous section.

A word on Tenant affinity

A best effort is made to keep Prefixes and IPAddresses together in the same Namespace by shared attributes such as Tenant, but this is not always possible for various reasons such as numerous duplicates with identical or too-closely-similar criteria.

For more information on how this is done please see the section Parenting affinity during the upgrade above.

If you find that you have objects that were moved to the wrong Namespaces, you might try the next section on swapping Namespaces.

Swapping Namespaces

If you need to swap a duplicate object into another Namespace (say "Global" and "Cleanup Namespace 1") where it conflicts with one in the desired Namespace, you can use this basic strategy to facilitate moving duplicate objects between Namespaces by using a temporary interstitial Namespace.

In this example we'll use three Namespaces. "Global", the Namespace in which you have duplicate objects that are found in "Cleanup Namespace 1", but you would like them to be the "Global" Namespace. We'll create a third Namespace called "Temporary" to act as the go-between to temporarily hold objects from one Namespace that we want to swap into another.

  • First, Create a new Namespace named "Temporary"
  • Next, edit any desired objects you want to swap in objects from the "Global" Namespace and update their Namespace to "Temporary"
    • After performing this step, there should be no duplicates found in the "Global" Namespace
  • Next, edit the duplicate objects you want moved in from "Cleanup Namespace 1" and set their Namespace to "Global".
    • After performing this step there should be no duplicates found in the "Cleanup Namespace 1" Namespace, as they've been moved to "Global"
  • Finally, edit the original objects found in the "Temporary" Namespace that were moved from "Global" to "Temporary" and set their Namespace "Cleanup Namespace 1"
    • After performing this final step, the duplicate objects that were originally in the "Global" have now been swapped with those that were originally in the "Cleanup Namespace 1" Namespace.
    • There are no duplicate objects found in the "Temporary" Namespace. This Namespace can safely be deleted.
  • Delete the "Temporary" Namespace when done.

Merge duplicate IP Addresses

After upgrading to Nautobot v2.0 and running the data migrations necessary, duplicate IPAddress objects might exist in your database. We define duplicate IPAddress objects as those which have the same host attribute but exist in different Namespaces. If you have no use case to keep those duplicate IPAddress objects around, we recommend you to use this tool to de-duplicate those IPAddress objects and keep your database clean and manageable. But if you do have reasons to maintain duplicate IPAddress objects, this tool is not for you.

For more information, please see the documentation on the Duplicate IP Address Merge Tool.

Delete duplicate objects

Because preventing data loss is prioritized, some objects that may have been required to be duplicates before may no longer be needed. For objects that weren't covered by the Duplicate IP Address Merge Tool, deleting objects might be your next course of action.

Some examples include:

  • The same IPAddress assigned to multiple Interfaces/VMInterfaces. Where possible, a single IPAddress is now assigned leaving duplicate objects across other Namespaces to be potentially no longer necessary.
  • VRFs that were used strictly for custom uniqueness boundaries with enforce_unique set to True may not necessarily be needed.

Cleanup your config

Remove the now-deprecated settings from your