Migrate Network Scripts and ifcfg Files to NetworkManager

Enterprise Linux is moving from legacy ifcfg-* profiles and the old network service to NetworkManager keyfiles. The removal schedule differs across RHEL-compatible distributions, but Enterprise Linux 10-family releases generally expect NetworkManager keyfiles and no longer load legacy ifcfg profiles. This playbook shows how to inventory what you have, pick the right migration path, convert profiles with nmcli connection migrate, and validate the result before the next major release.

The decision process applies across RHEL-compatible Linux distributions, although package availability and removal timing can differ. I tested automatic profile migration on Rocky Linux 9.8 in a container and validated keyfile behavior on Rocky Linux 10.2 hosts. Sections involving Leapp or release-specific removals identify the applicable distribution explicitly.

Tested on: Rocky Linux 9.8 (container); NetworkManager 1.54.3. Rocky Linux 10.2 (Red Quartz); NetworkManager 1.56.0. The container test covered static profile conversion. Bond, VLAN, physical-interface, and reboot validation must be performed on a host matching the actual network topology.

Choose the correct migration path

Start with the situation on the machine today. The fix for a host that already uses keyfiles is not the same as one still managed by the legacy network service or a network team.

Jump to the section that matches your host:

• Inventory the existing network configuration
• Migrate NetworkManager-managed ifcfg profiles
• Handle profiles that need manual work
• Validate the migrated network configuration
• Prepare for the next major-version upgrade
• Troubleshoot migration problems

Understand what is being migrated

Three different layers often get lumped together. Separating them keeps the migration plan accurate.

An ifcfg-* file on disk does not prove the legacy network service is active. On most current RHEL-family systems, NetworkManager already owns the interface and loads that file through the ifcfg-rh plugin. The migration goal is to move the same logical profile into a keyfile while NetworkManager still understands the source format.

Old and new profile locations:

/etc/sysconfig/network-scripts/ifcfg-*
/etc/NetworkManager/system-connections/*.nmconnection

Compatibility across distribution generations

Exact removal timing can differ between Oracle Linux, CentOS Stream, and RHEL rebuilds. Use the FILENAME column from nmcli and the compatibility table instead of assuming every distribution dropped ifcfg in the same minor release.

Inventory the existing network configuration

Before you change stored profiles, record which service owns the interfaces and what format NetworkManager reports.

Confirm NetworkManager is running:

systemctl is-active NetworkManager

Sample output:

active

Check whether NetworkManager starts at boot:

systemctl is-enabled NetworkManager

Sample output:

enabled

See which packages are installed:

rpm -q NetworkManager network-scripts

On Rocky Linux 9 the network-scripts RPM may be absent even when ifcfg profiles still exist. On Rocky Linux 10.2 in my lab, only NetworkManager was installed:

NetworkManager-1.56.0-1.el10.x86_64
package network-scripts is not installed

List devices and their active connections:

nmcli device status

Sample output:

DEVICE  TYPE      STATE                   CONNECTION
enp0s3  ethernet  connected               enp0s3
enp0s8  ethernet  connected               Wired connection 1
lo      loopback  connected (externally)  lo

The FILENAME field is the fastest way to see whether a profile is still stored as ifcfg or already a keyfile:

nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME connection show

Sample output on a host that still uses ifcfg:

NAME         UUID                                  TYPE      DEVICE  FILENAME
migrate-lab  4e194c3e-dacc-d422-77cb-9fd076c4e5f9  ethernet  --      /etc/sysconfig/network-scripts/ifcfg-migrate-lab

Sample output on Rocky Linux 10.2 after earlier keyfile adoption:

NAME                UUID                                  TYPE      DEVICE  FILENAME
enp0s3              8e253ab6-b35d-3500-826f-61b92fa7bc14  ethernet  enp0s3  /etc/NetworkManager/system-connections/enp0s3.nmconnection
Wired connection 1  5d09bf91-b93c-3457-a8b5-f6032b763ca4  ethernet  enp0s8  /run/NetworkManager/system-connections/Wired connection 1.nmconnection
lo                  1f6033f1-c691-4fd5-b4cd-1d8e7c440a2f  loopback  lo      /run/NetworkManager/system-connections/lo.nmconnection

Paths under /run/NetworkManager/system-connections/ are runtime profiles. Persistent lab or production profiles should end up under /etc/NetworkManager/system-connections/ before you treat migration as complete.

Inspect the effective NetworkManager configuration for explicitly configured settings plugins:

NetworkManager --print-config | grep -E '^\[main\]|plugins|dhcp='

Abridged sample output on Rocky Linux 9 when the ifcfg-rh plugin is still active:

[main]
plugins=ifcfg-rh,keyfile

On Rocky Linux 10.2 the same command may show only commented defaults because keyfile is the practical storage format:

[main]
# plugins=
# dhcp=internal

Do not use the plugins= line alone to decide whether migration is supported because plugin defaults can be implicit. The reliable test is the FILENAME column: if nmcli connection show lists the profile with an /etc/sysconfig/network-scripts/ifcfg-* filename, NetworkManager has loaded it and the profile can be targeted for migration.

Record the live network state before you rewrite stored profiles:

ip -br address
ip route show
ip -6 route show
ip rule show
nmcli device show

Addresses, routes, and device details are host-specific. Save the transcripts beside the nmcli connection show output so you can compare after migration.

Inspect the legacy directory for files that automatic migration may not fully translate:

ifcfg-*
route-* and route6-*
rule-* and rule6-*
ifup-local
custom ifup-* or ifdown-* hooks
DHCP exit hooks
alias interface files
profiles containing NM_CONTROLLED=no

Flag these configurations for extra review:

• Static addresses and multiple addresses on one interface
• Multiple default gateways and route metrics
• Policy-based routing (rule-* files)
• Bond, bridge, and VLAN parents
• Network teams (TYPE=Team)
• Custom interface names tied to DEVICE and HWADDR
• Cloud-init-generated ifcfg profiles
• Hosts whose NetworkManager configuration sets dhcp=dhclient
• Connections referenced by virtualization, storage, or HA services

Keep console or out-of-band access available while you migrate the profile that carries your administrative SSH session. For day-to-day nmcli syntax outside migration, see the nmcli command cheat sheet.

Map ifcfg variables to NetworkManager properties

Use this table to validate a converted profile with nmcli connection show instead of comparing raw files line by line.

Some mappings are inverted. PEERDNS=no becomes ipv4.ignore-auto-dns=yes, not a property named peerdns.

Older NetworkManager versions may display the deprecated aliases connection.master and connection.slave-type. Current releases prefer connection.controller and connection.port-type.

IPv6 does not follow a single one-to-one cheat sheet. After migration, inspect ipv6.method, addresses, gateways, DNS, and routes explicitly rather than assuming every IPV6* variable translated literally.

Migrate NetworkManager-managed ifcfg profiles

Start with one non-critical profile when you can. Use the connection UUID in commands when duplicate NAME values exist.

List profiles with their backing files:

nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME connection show

Migrate one profile by UUID:

nmcli connection migrate 4e194c3e-dacc-d422-77cb-9fd076c4e5f9

Sample output:

Connection 'migrate-lab' (4e194c3e-dacc-d422-77cb-9fd076c4e5f9) successfully migrated.

Migrate every profile the installed NetworkManager can convert:

nmcli connection migrate

Running the command without a profile ID targets all eligible profiles and stores the result with the keyfile plugin by default.

Confirm where each profile is stored afterward:

nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME connection show

After a successful ifcfg conversion, the FILENAME column should point under /etc/NetworkManager/system-connections/ and the legacy ifcfg file should be gone:

NAME         UUID                                  TYPE      DEVICE  FILENAME
migrate-lab  4e194c3e-dacc-d422-77cb-9fd076c4e5f9  ethernet  --      /etc/NetworkManager/system-connections/migrate-lab.nmconnection

Worked example: static Ethernet ifcfg profile

The source ifcfg profile in the Rocky Linux 9 container lab looked like this:

TYPE=Ethernet
BOOTPROTO=none
NAME=migrate-lab
DEVICE=dummy-test
ONBOOT=no
IPADDR=192.168.99.50
PREFIX=24

After migration, the important properties were:

nmcli connection show migrate-lab

Abridged sample output:

connection.id:                          migrate-lab
connection.uuid:                        4e194c3e-dacc-d422-77cb-9fd076c4e5f9
connection.type:                        802-3-ethernet
connection.interface-name:              dummy-test
connection.autoconnect:                 no
ipv4.method:                            manual
ipv4.addresses:                         192.168.99.50/24
ipv6.method:                            ignore

The on-disk keyfile contained the same data in ini format:

[connection]
id=migrate-lab
uuid=4e194c3e-dacc-d422-77cb-9fd076c4e5f9
type=ethernet
autoconnect=false
interface-name=dummy-test

[ipv4]
address1=192.168.99.50/24
method=manual

[ipv6]
method=ignore

Use nmcli connection show as the primary validation step. When nmcli connection migrate is available on your source release, do not manually translate every ifcfg variable in the main workflow.

Complex topology: bond with a VLAN

Automatic migration also applies to bond and VLAN profiles, but you must verify controller and port relationships afterward. A common server layout looks like this:

enp0s8 + enp0s9  →  bond0  →  bond0.100 (VLAN 100)  →  application address

After migration, inspect each profile in the bond and VLAN stack:

nmcli connection show bond0
nmcli connection show bond0-port-enp0s8
nmcli connection show bond0.100

Compare connection.controller, connection.port-type, vlan.parent, and address fields against your pre-migration inventory.

For new bond or bridge design outside migration, see configure a network bridge with nmcli.

Handle profiles that need manual work

Automatic migration covers most NetworkManager-managed ifcfg profiles. The cases below need deliberate recreation or follow-up edits.

Legacy network-service profiles

If systemctl is-active network reports active, or the interface comes up without a NetworkManager connection, the legacy network service still owns the configuration.

Recreate the configuration under NetworkManager instead of running nmcli connection migrate on a profile that does not exist yet:

1. Recreate the address, prefix, gateway, DNS, routes, and autoconnect settings using nmcli or nmtui.
2. Confirm that the new connection is stored under /etc/NetworkManager/system-connections/.
3. Activate it and validate connectivity.
4. Retire the legacy network service after NetworkManager owns the device.

Profiles created with nmcli or nmtui on a current EL9 system are normally keyfiles already, so no further format migration is required.

Copying an ifcfg file into /etc/NetworkManager/system-connections/ is not a valid conversion. If network.service is already missing, see unit network.service not found for the modern replacement commands.

Complex connection types

After migration, explicitly verify:

• Bond controller relationships on each port profile (connection.controller and connection.port-type)
• Bridge controller and port relationships
• VLAN parent interface names and VLAN IDs
• Multiple IPv4 or IPv6 addresses on one connection
• Static routes, table IDs, and metrics
• Policy-routing rules from rule-* files
• IPv6 default-route behavior when both address families are in use

For policy-routing validation after conversion, compare ip rule show and the ipv4.routing-rules / ipv6.routing-rules properties against your inventory. Detailed policy-routing design belongs in a dedicated routing guide; this article only checks that migrated rules survived.

Network teams

Releases without teamd require a bond instead of a network team. Plan a separate team-to-bond conversion before the major upgrade rather than expecting nmcli connection migrate to rewrite TYPE=Team into a supported controller on EL 10. The older NIC teaming guide shows the legacy team layout for comparison only.

On RHEL 9, the team2bond utility can convert the team controller and port configuration. It does not carry over IP addresses, DNS, or every higher-level connection setting, so record those values first and configure them manually on the resulting bond.

Scripts and generated configurations

Dispatcher scripts belong here:

/etc/NetworkManager/dispatcher.d/

Update the original provisioning source. Otherwise cloud-init, Ansible, or another tool may recreate the deleted ifcfg profile on the next boot or playbook run.

Custom interface names

An ifcfg profile could participate in renaming through DEVICE and HWADDR. A keyfile alone does not reproduce that older renaming mechanism. When a custom name must survive migration, back it with a systemd .link file or a udev rule, then point the connection at the stable interface name.

Validate the migrated network configuration

Migration is not finished when nmcli connection migrate exits zero. Validate stored profiles, runtime state, permissions, and reboot behavior.

Check stored profile locations again:

nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME connection show

Inspect one connection in detail:

nmcli connection show enp0s3

Validate runtime state against your inventory:

nmcli device status
ip -br address
ip route show

When the host uses IPv6 defaults, policy routing, or multiple tables, repeat ip -6 route show and ip rule show the same way you did during inventory.

Confirm all of the following before you call the host done:

• Expected IPv4 and IPv6 addresses are assigned
• The correct interface owns each address
• Default gateways and route metrics match the pre-migration inventory
• Static routes and routing rules are still present
• DNS servers and search domains are correct
• Bond, bridge, and VLAN ports attach to the expected controller
• Autoconnect behavior matches the old ONBOOT setting
• Dependent services can still reach required endpoints

Check keyfile ownership and permissions:

stat /etc/NetworkManager/system-connections/*.nmconnection

Sample output:

File: /etc/NetworkManager/system-connections/enp0s3.nmconnection
  Access: (0600/-rw-------)  Uid: (0/root)   Gid: (0/root)

Persistent keyfiles should be owned by root with mode 0600. NetworkManager can ignore profiles that are group- or world-readable.

After live validation, reboot from console or a controlled maintenance window. The goal is to prove the stored keyfile—not only the previous runtime state—recreates addresses, routes, DNS, and controller-port relationships at boot.

Prepare for the next major-version upgrade

Use this checklist on the source release before you start the distribution upgrade:

1. Every required profile appears under /etc/NetworkManager/system-connections/.
2. No active connection still points to an ifcfg-* filename.
3. No required profile contains NM_CONTROLLED=no.
4. Network teams have been replaced by bonds where teamd will be unavailable.
5. On RHEL, replace dhcp=dhclient with dhcp=internal before upgrading to RHEL 10; the internal backend is the default.
6. Legacy ifup-*, ifdown-*, and DHCP hooks have dispatcher or unit replacements.
7. Cloud-init and configuration-management templates generate keyfiles.
8. Custom interface names are backed by systemd link files or udev rules.
9. A reboot successfully restores addresses, routes, DNS, and controller-port relationships.

On RHEL, run leapp preupgrade as an additional check before a supported in-place major upgrade. The full Leapp workflow belongs in a dedicated major-version upgrade guide; this article only ensures networking will survive the target release.

For Rocky Linux, AlmaLinux, Oracle Linux, and CentOS Stream, follow that distribution's documented upgrade path. Leapp behavior and preupgrade reports are not identical across every rebuild.

Troubleshoot migration problems

When a connection still fails after migration, compare the current profile against your pre-change inventory and use restart or reload network commands to apply stored settings without guessing at daemon state.

References

• RHEL 9: NetworkManager connection profiles in keyfile format
• RHEL 9: Migrating a NIC team configuration to a network bond
• RHEL 10: Upgrading from RHEL 9 to RHEL 10
• RHEL 10: Networking changes and removed ifcfg support
• RHEL 8: Legacy network-scripts support
• Rocky Linux: Network configuration
• Oracle Linux 10: NetworkManager connection profiles
• NetworkManager: nmcli reference
• NetworkManager: Keyfile format reference

Summary

Inventory whether NetworkManager or the legacy network service owns each interface, then migrate ifcfg profiles to keyfiles on the source release with nmcli connection migrate. Validate addresses, routes, DNS, bond and VLAN relationships, file permissions, and reboot behavior before you upgrade to Enterprise Linux 10 or another release that no longer reads /etc/sysconfig/network-scripts/ifcfg-*.