The device needs to be on its own port, or, if it shares a switch, all other devices on the switch will need to be on the NAP VLAN, and those devices will all need to be switched over at the same time.
Analyze how the device is currently used and how users connect to it.
A printer connected to a print server via IP or DNS name, and then shared to otherusers through that print server is a simple change. You make the one change on the print server and within minutes, users connected through the print server are printing to the new IP/DNS.
If you have local-computer connections, where each user makes its own direct connection to the device, you have to analyze how much effort it will take to change that connection. If users are using the static IP, you will have to make a change at each connection. If users are using a DNS name, you may not have to make any changes at the connection, but that depends on another factor described later on.
If you have local-computer connections from off-campus, the NAP VLAN is out of the question for the device, unless you set up an intermediary device/machine/computer to make the jump from public address/internet (WAN) to private network (LAN).
Once you analyze how the connections are made, you must then analyze what needs to stay the same and what can change.
First and foremost, the IP address must change.
Second, the DNS name. There cannot be duplicate names in DNS. Therefore, you must decide between a few options:
Create the new entry with a different DNS name, then switch everyone over to the new DNS name (difficult if you have multiple local connections, easy if you only have one connection through a print server).
Create the new entry with a different DNS name, but once you switch the device to the new IP address on the NAP VLAN, have the old DNS name point to the new DNS name (slightly longer of an outage, but reduces changes needed if you use the DNS name for connections
Create the new IP address/DNS name with a different DNS name, but once you switch the device to the new IP address on the NAP VLAN, delete the old DNS name and change the new IP address' DNS name to match the old one, (even longer of an outage, but still reduces the changes needed if you use the DNS name for connections, this also reduces confusion with multiple DNS names, but it is more work and more possibility for issues/longer outages).
Now you must plan when to make the change. You obviously don't want to change a printer's IP address during peak printing times. That being said, the IP change does not take very long, so scheduling when to do it with users should not be difficult.
As described above, you need the static IP/DNS entry created before you can continue
There are 5 different NAP VLAN subnets that are separated based on their VSS pair (location). Each subnet is a /21 subnet, so the subnet masks for every VLAN will be 255.255.248.0. The gateway will be 10.14.x.254 where x is different for each of the 5 subnets. So for example, if one of the subnets began at 10.14.100.0 and it is a /21 subnet, the gateway would be 10.14.107.254.
Make sure you know how the IP change will proceed on the device, whether you must do it locally or via the web, where the IP settings are located on the device, and what administrative passwords you may need.
Once you have the IP and MAC address of the device you will need to add the device to Clearpass. After adding the device to Clearpass and choosing the right VLAN in Clearpass, you will need to unplug the network cable from the device, wait a few seconds and then plug the cable back into the device.
Issues you may find:
Local software firewalls must allow traffic via this private address space and any hardware firewalls (mostly extremely locked-down firewalls) must also allow this traffic.
DNS caches might not clear/change right away if you change DNS names, depending on how the client machine accesses DNS.
The device most likely should be rebooted after the change, ESPECIALLY if the device is older or has been known to have network issues in the past. Error on the side of caution. A simple reboot is not as bad as the clock ticking trying to figure out why the device isn't talking to the network properly.