Before you Upgrade¶
This section covers how you can prepare your IPAM Data for Nautobot 2.0.
Run the pre-migration helper before upgrading¶
A new pre-migration management command was added that will allow you to check your existing data for compatibility with the data model changes introduced in Nautobot 2.0. You are highly encouraged to run this before upgrading!
For more information please see the documentation on Pre-migration validation.
You cannot migrate Interfaces or VMInterfaces that have IPs with differing VRFs¶
When assigning a
VRF to an
VRF must be the same across each IP when multiple
IPAddress objects are assigned to
Make sure for
VMInterfaces with multiple IPs that each
IPAddress1 assigned to the same
VMInterface share the same VRF, or are not assigned a VRF.
Parent Prefixes, child Prefixes, and child IPAddresses must share the same Namespace¶
IPAddresses must share the same
Namespace and any case for duplicate
IPAddress must involve leveraging distinct
If you need to maintain duplicates for any reason, assert that each set of duplicate objects are assigned to a distinct
enforce_unique set to
True, as during the upgrade process these will each be moved to their own "VRF Namespace". Please see the section on VRF Namespaces below for more information.
IPAddress objects can no longer be orphaned¶
IPAddresses must now always have a parent
Prefix to contain them. Any
IPAddress that does not have a parent is considered to be "orphaned" and as of Natutobot 2.0 this is not allowed.
When upgrading to Nautobot 2.0, the database migration will automatically create a parent
IPAddresses that do not have an eligible parent
Prefix. For example an
IPAddress with address of
220.127.116.11/32 will have a parent
Prefix created of the same
If you do not wish for these single-host
Prefixes to be created, create a parent
Prefix of your desired size to contain any would-be orphaned
IPAddresses before upgrading.
Prepare for Namespaces¶
After upgrading, there will be two distinct sets of extra
Namespace objects created based on specific conditions of your data set.
VRF objects with
enforce_unique enabled (which is the default), will be moved to "VRF Namespace" objects. Second, any duplicate objects will be moved to "Cleanup Namespace" objects.
Each of these are covered below.
After upgrading, any duplicate objects that were found in the "Global" Namespace will be moved to one or more "Cleanup" Namespaces. Cleanup Namespaces are named numerically. When duplicate objects are identified that are not associated with a VRF that has
enforce_unique set to
True, each Cleanup Namespace will be enumerated until one that does not have conflicting objects can be found. If one cannot be found, a new Cleanup Namespace will be created.
For example, the very first duplicate
Prefix found will be moved to a Namespace named "Cleanup Namespace 1". For each pass that identifies a duplicate of an object in an existing Namespace, new Namespaces will be created by incrementing the number resulting in "Cleanup Namespace 2", "Cleanup Namespace 3", etc.
Because Cleanup Namespaces will be created to avoid data loss, there is little you can do to avoid their creation during the upgrade process. You may want to review your Cleanup Namespaces or swap objects around between other Namespaces.
Please review any Cleanup Namespaces after you upgrade.
VRF objects that had
enforce_unique enabled with
Prefixes assigned to them, any child
Prefixes or child
IPAddresses of those
Prefixes will be moved to a "VRF Namespace" with the name of the
For example, if the
VRF is named "Blue" and has
Prefixes assigned to it, the
Prefixes assigned to it, and any child
IPAddresses will be moved to a new
Namespace with the name "VRF Namespace Blue".
If you wish to reduce the need for creation of VRF Namespaces, review your existing
VRF objects with
enforce_unique enabled to identify their relevance. If you do not require enforcing uniqueness in the VRF itself, you may toggle
enforce_unique to tell Nautobot to handle any potential duplicates globally instead, which may result in duplicate objects being moved to Cleanup Namespaces that will need to be reviewed following the upgrade process.
Please review any Cleanup or VRF Namespaces after you upgrade.
Aggregate model was merged into Prefix¶
Aggregate model was removed and all existing aggregates will be migrated to
Prefix with type set to
Aggregate.date_added field will be migrated to
Prefix.date_allocated and changed from a
Date field to a
DateTime field with the time set to
00:00. The fields
Aggregate.description will be migrated over to the same fields on
Prefix already exists with the same network and prefix length as a previous
date_added fields will be copied to the
date_allocated fields on the existing Prefix object. Messages will be output during migration (
nautobot-server migrate or
nautobot-server post_upgrade) if the
type fields need to be manually migrated.