Convert clients one workgroup at a time, and convert all workgroups in a subnet before starting on those of another subnet. That way, when you convert all the clients in a subnet, you can eliminate the NIS service on that subnet. Run the verification script after converting each client to make sure that the conversion worked properly. That verification script should inform the user which support structure is in place, to help with problems and how to report them. The actual steps required depend on the site.
You can also save time if your site has a shared, mounted central directory similar to /usr/local. You could put the script in the central directory and, on the day of conversion, send email to clients asking them to run the script as superuser.
Monitor the status of the transition as clients are being converted.
Track progress against your plan and all serious complications not anticipated in the planning stages. Announce your status so that interested parties can track it.
As all the clients on a subnet are converted to NIS+, decommission the NIS servers. If a particular subnet has some clients that require NIS service, use the NIS-compatibility feature of the NIS+ servers but do not retain the NIS servers.
After the implementation is complete, test to see that NIS+ is working correctly.
Based on the results of your performance evaluation, modify the NIS+ environment as needed. These improvements can be as simple as adding selected replicas in domains with high loads or as involved as rearranging the storage of NIS+ information for a group of domains.
If you did not change old domain names during the transition for the sake of simplicity, upgrade them now to the new NIS+ naming scheme. For example, if you left some domains with geographic labels while you converted to an organizational hierarchy, you now change the geographic names to their organizational versions.