Import from Export #8951

New Issue

adam · 2025-12-29T20:43:15+01:00

adam commented

2025-12-29 20:43:15 +01:00

Originally created by @LHBL2003 on GitHub (Dec 12, 2023).

NetBox version

v3.6.6

Feature type

Change to existing functionality

Proposed functionality

An export in human form is possible. However, this cannot be imported again without adjustments. A "Current View - For Import" and "All Data (CSV) - For Import" button is helpful to enable mass engineering. This is because the exported version is not compatible for import, as the display names are used, among other things. Also in some cases texts are displayed instead of IDs (as far as I remember)

Use case

Advantages:

you immediately have a sample template in the export so that you can import directly with minor adjustments, e.g. if you have to create hundreds of IP addresses and segments for a new location that differ slightly.
if the ID has also been specified, you can quickly adjust the contents via Excel or similar if something has changed significantly or if you want to make adjustments to the description, for example. Editing hundreds or thousands of entries via the web interface, on the other hand, is much slower.
you can customize many things without having to write / understand a script via Rest-API / Pyton Shell.

An import and export via CSV in combination with Excel is a powerful tool for any user to make mass changes without much background knowledge.
This is why CSV import and export can also be found in many industrial software applications to be able to work quickly and efficiently. It takes a lot of time to familiarize yourself with the Rest API or Pyton shell and if you don't use it daily, you need even more time to familiarize yourself again. It is also very time-consuming compared to some Excel work. In Excel you have the solution ready in a few minutes. Regardless of whether you discard, save or rewrite the Excel afterwards, it is much more efficient, especially if it doesn't have to be automated. And if something changes in Netbox, you can react quickly because you can quickly understand the CSV export.

Translated with www.DeepL.com/Translator (free version)
Mass engineering through import and export would be possible. I and many others would use this function more often if it wasn't so inconvenient to re-import something that has been exported.
See also: #7653

I, at least, have been wishing for this function for several years.

Database changes

No response

External dependencies

No response

Originally created by @LHBL2003 on GitHub (Dec 12, 2023). ### NetBox version v3.6.6 ### Feature type Change to existing functionality ### Proposed functionality An export in human form is possible. However, this cannot be imported again without adjustments. A "Current View - For Import" and "All Data (CSV) - For Import" button is helpful to enable mass engineering. This is because the exported version is not compatible for import, as the display names are used, among other things. Also in some cases texts are displayed instead of IDs (as far as I remember) ### Use case Advantages: 1. you immediately have a sample template in the export so that you can import directly with minor adjustments, e.g. if you have to create hundreds of IP addresses and segments for a new location that differ slightly. 2. if the ID has also been specified, you can quickly adjust the contents via Excel or similar if something has changed significantly or if you want to make adjustments to the description, for example. Editing hundreds or thousands of entries via the web interface, on the other hand, is much slower. 3. you can customize many things without having to write / understand a script via Rest-API / Pyton Shell. An import and export via CSV in combination with Excel is a powerful tool for any user to make mass changes without much background knowledge. This is why CSV import and export can also be found in many industrial software applications to be able to work quickly and efficiently. It takes a lot of time to familiarize yourself with the Rest API or Pyton shell and if you don't use it daily, you need even more time to familiarize yourself again. It is also very time-consuming compared to some Excel work. In Excel you have the solution ready in a few minutes. Regardless of whether you discard, save or rewrite the Excel afterwards, it is much more efficient, especially if it doesn't have to be automated. And if something changes in Netbox, you can react quickly because you can quickly understand the CSV export. Translated with www.DeepL.com/Translator (free version) Mass engineering through import and export would be possible. I and many others would use this function more often if it wasn't so inconvenient to re-import something that has been exported. See also: #[7653](https://github.com/netbox-community/netbox/discussions/7653) I, at least, have been wishing for this function for several years. ### Database changes _No response_ ### External dependencies _No response_

adam added the type: feature status: under review labels 2025-12-29 20:43:15 +01:00

adam closed this issue

2025-12-29 20:43:16 +01:00

adam commented

2025-12-29 20:43:16 +01:00

@jeremystretch commented on GitHub (Dec 12, 2023):

The reason for this is already explained in the wiki. You also haven't cited your use case: Why do you find yourself needing to re-import data from NetBox back into NetBox?

(Also, could you translate the last line under "proposed functionality" above to English please?)

@jeremystretch commented on GitHub (Dec 12, 2023): The reason for this is already [explained in the wiki](https://github.com/netbox-community/netbox/wiki/Frequently-Asked-Questions#why-cant-i-pass-exported-data-directly-into-the-import-form). You also haven't cited your use case: _Why_ do you find yourself needing to re-import data from NetBox back into NetBox? (Also, could you translate the last line under "proposed functionality" above to English please?)

adam commented

2025-12-29 20:43:16 +01:00

@LHBL2003 commented on GitHub (Dec 12, 2023):

Sorry, the sentence has been translated and the Use case section has been revised.

@LHBL2003 commented on GitHub (Dec 12, 2023): Sorry, the sentence has been translated and the Use case section has been revised.

adam commented

2025-12-29 20:43:17 +01:00

@jeremystretch commented on GitHub (Dec 14, 2023):

you immediately have a sample template in the export so that you can import directly with minor adjustments, e.g. if you have to create hundreds of IP addresses and segments for a new location that differ slightly.

This is already included at the bottom of every import page, along with descriptions of each field and (where applicable) available choices. These are not present in an exported document. It would also not be clear from an exported document that referencing related objects by alternative identifiers (i.e. slug or id) is possible.

if the ID has also been specified, you can quickly adjust the contents via Excel or similar if something has changed significantly or if you want to make adjustments to the description, for example. Editing hundreds or thousands of entries via the web interface, on the other hand, is much slower.

It should be considered an anti-pattern to ever need to leave the application to manipulate application data. NetBox already has robust bulk edit abilities: I'll admit these are far from perfect, but you're welcome to submit a feature request if you'd like to propose specific improvements.

you can customize many things without having to write / understand a script via Rest-API / Pyton Shell.

I'm not sure what you're referring to by "customize" here, but both the REST API and native Python shell are incredibly powerful tools that far exceed the capabilities of importing a static document. Despite the modest learning curve, they are typically preferable solutions to attempting to effect bulk changes via the re-import of bulk data.

As I've discussed previously, NetBox exports data in a format that it expects to be most useful for other systems. This includes details such as using human-friendly column headers and displaying translated labels for choice fields rather than their raw values. This is done because we naturally assume data being exported from NetBox is destined for someplace other than NetBox.

It would be both foolish of us to ditch these recipient-friendly touches in favor of an approach that serves only a circular workflow where NetBox data is fed directly back into NetBox. I suspect if we spend more time considering your specific use cases above we can arrive at more suitable solutions, or at least a tenable path toward them.

@jeremystretch commented on GitHub (Dec 14, 2023): > 1. you immediately have a sample template in the export so that you can import directly with minor adjustments, e.g. if you have to create hundreds of IP addresses and segments for a new location that differ slightly. This is already included at the bottom of every import page, along with descriptions of each field and (where applicable) available choices. These are not present in an exported document. It would also not be clear from an exported document that referencing related objects by alternative identifiers (i.e. `slug` or `id`) is possible. > 2. if the ID has also been specified, you can quickly adjust the contents via Excel or similar if something has changed significantly or if you want to make adjustments to the description, for example. Editing hundreds or thousands of entries via the web interface, on the other hand, is much slower. It should be considered an anti-pattern to ever need to leave the application to manipulate application data. NetBox already has robust bulk edit abilities: I'll admit these are far from perfect, but you're welcome to submit a feature request if you'd like to propose specific improvements. > 3. you can customize many things without having to write / understand a script via Rest-API / Pyton Shell. I'm not sure what you're referring to by "customize" here, but both the REST API and native Python shell are incredibly powerful tools that far exceed the capabilities of importing a static document. Despite the modest learning curve, they are typically preferable solutions to attempting to effect bulk changes via the re-import of bulk data. As I've discussed previously, NetBox exports data in a format that it expects to be most useful for _other systems_. This includes details such as using human-friendly column headers and displaying translated labels for choice fields rather than their raw values. This is done because we naturally assume data being exported from NetBox is destined for someplace _other than NetBox_. It would be both foolish of us to ditch these recipient-friendly touches in favor of an approach that serves only a circular workflow where NetBox data is fed directly back into NetBox. I suspect if we spend more time considering your specific use cases above we can arrive at more suitable solutions, or at least a tenable path toward them.

adam commented

2025-12-29 20:43:17 +01:00

@nopg commented on GitHub (Dec 19, 2023):

Re: "Why do you find yourself needing to re-import data from NetBox back into NetBox?", one use case is having a test/second Netbox server that you would like to move all xyz devices/circuits/whatever into this 'other' instance of Netbox (ie, export from here, import over there, both are 'Netbox').

If the answer/response to that is to use Postgres directly instead, maybe a quick blurb about that being preferred (or whatever method is preferred for this) in the same wiki explaining why this is not supported (without export templates) could be added.

@nopg commented on GitHub (Dec 19, 2023): Re: "Why do you find yourself needing to re-import data from NetBox back into NetBox?", one use case is having a test/second Netbox server that you would like to move all xyz devices/circuits/whatever into this 'other' instance of Netbox (ie, export from here, import over there, both are 'Netbox'). If the answer/response to that is to use Postgres directly instead, maybe a quick blurb about that being preferred (or whatever method is preferred for this) in the same wiki explaining why this is not supported (without export templates) could be added.

adam commented

2025-12-29 20:43:17 +01:00

@jeremystretch commented on GitHub (Dec 19, 2023):

If the answer/response to that is to use Postgres directly instead

Manipulating the database directly is practically never the answer. Most of NetBox's core business and validation logic lives in the Python code, not in the database, and circumventing this logic will inevitably lead to pain and sadness.

As I mentioned above, NetBox provides not one but two powerful APIs for manipulating data programmatically: the high-level REST API and the low-level Python shell. While the later demands comprehension of Python and some development fundamentals, both are supported and both provide far more robust capability than the simple bulk import/export mechanisms.

@jeremystretch commented on GitHub (Dec 19, 2023): > If the answer/response to that is to use Postgres directly instead Manipulating the database directly is practically _never_ the answer. Most of NetBox's core business and validation logic lives in the Python code, not in the database, and circumventing this logic will inevitably lead to pain and sadness. As I mentioned above, NetBox provides not one but _two_ powerful APIs for manipulating data programmatically: the high-level [REST API](https://docs.netbox.dev/en/stable/features/api-integration/#rest-api) and the low-level [Python shell](https://docs.netbox.dev/en/stable/administration/netbox-shell/). While the later demands comprehension of Python and some development fundamentals, both are supported and both provide far more robust capability than the simple bulk import/export mechanisms.

adam commented

2025-12-29 20:43:17 +01:00

@jeremystretch commented on GitHub (Jan 12, 2024):

Closing this out as no action is needed.

@jeremystretch commented on GitHub (Jan 12, 2024): Closing this out as no action is needed.

adam commented

2025-12-29 20:43:17 +01:00

@polski-g commented on GitHub (Feb 7, 2024):

The reason for this is already explained in the wiki. You also haven't cited your use case: Why do you find yourself needing to re-import data from NetBox back into NetBox?

(Also, could you translate the last line under "proposed functionality" above to English please?)

In some industries, a customer might demand that all of their data be segregated from anyone else's -- in which case, you'd be required to setup and migrate to separate password managers, IPAMs, monitoring infrastructure, etc. This has happened several times in my career. So the target feature would be: an easy way to extract Netbox data from customer A and then re-import it into a standalone Netbox just for that customer.

@polski-g commented on GitHub (Feb 7, 2024): > The reason for this is already [explained in the wiki](https://github.com/netbox-community/netbox/wiki/Frequently-Asked-Questions#why-cant-i-pass-exported-data-directly-into-the-import-form). You also haven't cited your use case: _Why_ do you find yourself needing to re-import data from NetBox back into NetBox? > > (Also, could you translate the last line under "proposed functionality" above to English please?) In some industries, a customer might demand that all of their data be segregated from anyone else's -- in which case, you'd be required to setup and migrate to separate password managers, IPAMs, monitoring infrastructure, etc. This has happened several times in my career. So the target feature would be: an easy way to extract Netbox data from customer A and then re-import it into a standalone Netbox just for that customer.

adam commented

2025-12-29 20:43:18 +01:00

@jeremystretch commented on GitHub (Feb 7, 2024):

And that is much more readily accomplished using NetBox's powerful, programmatic REST API or Python shell. Trying to do that by re-importing bulk export data would be foolish when far superior tools exist.

@jeremystretch commented on GitHub (Feb 7, 2024): And that is _much_ more readily accomplished using NetBox's powerful, programmatic REST API or Python shell. Trying to do that by re-importing bulk export data would be foolish when far superior tools exist.

adam commented

2025-12-29 20:43:18 +01:00

@LHBL2003 commented on GitHub (Feb 7, 2024):

I was just thinking yesterday how nice it would be to simply export via csv, quickly customise via Notepad++ and import again quickly and easily.
Descriptions in particular can be adapted much more quickly without having to think too much about it.

But I will take the time to have a look at Powershell in the next few days. But I doubt that this is easier than simply changing values via excel or text file. Especially if each line expects a different value.

Is there a possible Getting starts?
Or do you have some links that I should definitely check out? At least I have experience with Powershell under Windows.

@LHBL2003 commented on GitHub (Feb 7, 2024): I was just thinking yesterday how nice it would be to simply export via csv, quickly customise via Notepad++ and import again quickly and easily. Descriptions in particular can be adapted much more quickly without having to think too much about it. But I will take the time to have a look at Powershell in the next few days. But I doubt that this is easier than simply changing values via excel or text file. Especially if each line expects a different value. Is there a possible Getting starts? Or do you have some links that I should definitely check out? At least I have experience with Powershell under Windows.

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#8951