Add an import/export function for migrating "custom_fields" between instances of NetBox. #1516

New Issue

adam · 2025-12-29T16:32:37+01:00

adam commented

2025-12-29 16:32:37 +01:00

Originally created by @bdlamprecht on GitHub (Jan 29, 2018).

Issue type

[X] Feature request
[ ] Bug report
[ ] Documentation

Environment

Python version: Python 2.7.12
NetBox version: v2.2.8

Description

Currently, I'm working on migrating from a development instance of NetBox to a production instance and would like to move a number of custom_fields that I've created specific to this customer between these two instances. While I could manually create them by hand and at present would not be too much of a problem to do, once this goes live into production, I expect a lot of other needs are going to pop up requiring additional custom_fields which I'll have to test against in the my development instance. Also, inconsistencies may occur due to the "human element", so that is, in my opinion, a non-starter.

@lampwins helped kind of helped me do it with a pg_dump command and they were imported without any errors being reported, however, when I did this, the custom_fields were mapped to the incorrect models and I had to go into the Admin site and re-map them.

How difficult do you think this functionality would be to implement?

Originally created by @bdlamprecht on GitHub (Jan 29, 2018). ### Issue type [X] Feature request  [ ] Bug report  [ ] Documentation  ### Environment * Python version: Python 2.7.12 * NetBox version: v2.2.8 ### Description Currently, I'm working on migrating from a development instance of NetBox to a production instance and would like to move a number of `custom_fields` that I've created specific to this customer between these two instances. While I **_could_** manually create them by hand and at present would not be too much of a problem to do, once this goes live into production, I expect a lot of other needs are going to pop up requiring additional `custom_fields` which I'll have to test against in the my development instance. Also, inconsistencies may occur due to the "human element", so that is, in my opinion, a non-starter. @lampwins helped kind of helped me do it with a `pg_dump` command and they were imported without any errors being reported, however, when I did this, the `custom_fields` were mapped to the incorrect `models` and I had to go into the Admin site and re-map them. How difficult do you think this functionality would be to implement?

adam closed this issue

2025-12-29 16:32:37 +01:00

adam commented

2025-12-29 16:32:37 +01:00

@lampwins commented on GitHub (Jan 29, 2018):

To add some more context:

The issue we ran into is on the import, each custom field is sometimes (most of the time) mapped to the wrong netbox models. Best I can tell, this is due to ContentType id's for models being unique to a django installation (assumption on my part).

I think there is value in this feature from a netbox development and testing standpoint. As more people start to use netbox in automation flows, the need to run dev/test instances of netbox will certainly increase and so will the need to ensure those environments are identical.

@lampwins commented on GitHub (Jan 29, 2018): To add some more context: The issue we ran into is on the import, each custom field is sometimes (most of the time) mapped to the wrong netbox models. Best I can tell, this is due to `ContentType` id's for models being unique to a django installation (assumption on my part). I think there is value in this feature from a netbox development and testing standpoint. As more people start to use netbox in automation flows, the need to run dev/test instances of netbox will certainly increase and so will the need to ensure those environments are identical.

adam commented

2025-12-29 16:32:37 +01:00

@cimnine commented on GitHub (Jan 31, 2018):

For inspiration how such a feature might work, and until such a feature is built-in to Netbox, you may find my little script for declaring and importing custom fields useful.

I don't usually write python code, so there might be a more elegant solution than this particular implementation, yet I think the concept is very intuitive.

@cimnine commented on GitHub (Jan 31, 2018): For inspiration how such a feature might work, and until such a feature is built-in to Netbox, you may find [my little script][gist] for declaring and importing custom fields useful. I don't usually write python code, so there might be a more elegant solution than this particular implementation, yet I think the concept is very intuitive. [gist]: https://gist.github.com/cimnine/f3591d26ecc41111563ff26741669c6c

adam commented

2025-12-29 16:32:37 +01:00

@jeremystretch commented on GitHub (Jan 31, 2018):

I'd like to avoid exposing custom fields as objects in the front end (to preserve the demarcation between data and schema), but we can probably implement some form of import/export function in the admin UI.

@jeremystretch commented on GitHub (Jan 31, 2018): I'd like to avoid exposing custom fields as objects in the front end (to preserve the demarcation between data and schema), but we can probably implement some form of import/export function in the admin UI.

adam commented

2025-12-29 16:32:38 +01:00

@cimnine commented on GitHub (Feb 1, 2018):

Maybe this must not even be a feature in the UI but could be implemented through manage.py?

@cimnine commented on GitHub (Feb 1, 2018): Maybe this must not even be a feature in the UI but could be [implemented through `manage.py`](https://docs.djangoproject.com/en/2.0/howto/custom-management-commands/)?

adam commented

2025-12-29 16:32:38 +01:00

@jeremystretch commented on GitHub (Jun 27, 2019):

Revisiting this. It seems like it's simple enough to do using Django's built-in dumpdata and loaddata management commands:

./manage.py dumpdata extras.customfield --indent 4 > customfields.json

./manage.py loaddata customfields.json

The content type IDs referenced by obj_type might need to be updated by hand if importing to a different NetBox instance, but I think that's a reasonable limitation given how infrequently it's likely to be used. Anything more involved is probably going to require some degree of custom scripting anyway.

@jeremystretch commented on GitHub (Jun 27, 2019): Revisiting this. It seems like it's simple enough to do using Django's built-in `dumpdata` and `loaddata` management commands: ``` ./manage.py dumpdata extras.customfield --indent 4 > customfields.json ``` ``` ./manage.py loaddata customfields.json ``` The content type IDs referenced by `obj_type` might need to be updated by hand if importing to a different NetBox instance, but I think that's a reasonable limitation given how infrequently it's likely to be used. Anything more involved is probably going to require some degree of custom scripting anyway.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#1516