Hello,
There is hardly any checklist available, as this is, to a great extent, an application-layer specific issue, and the application layer is very diverse, so it's hard to have any extensive globally valid recommendations.
Nevertheless, the changeover from .com to .net domain is primarily about your site being available under a different name but not under different addressing. Hence, from the point of IP addressing and routing, nothing changes. What changes, though, are the application settings that reacted to .com before and now have to react to both .com and .net to provide a smooth transition. Therefore, you must identify all your applications and services that depend on Fully Qualified Domain Names or use them as part of their operation, and make sure that their configuration is updated so that they provide the same set of services for both .com and .net versions of your domain. This includes, but is not limited to, web services, e-mail services, IP telephony (SIP/H.323), Instant Messaging (if you're using XMPP/SIMPLE/whatever), DHCP, Active Directory (if for some reason tied to the DNS domain), internal DNS servers, ... Please note that each of these services may go to great lengths about what exactly needs to be updated: for example, in HTTP,
- All your webserves must be configured to recognize both .com and .net names
- New SSL certificates must be issued for .net versions of your sites if you are using HTTPS
- All hyperlinks in your HTML pages must be converted from .com to .net
- Redirection should be configured so that when a .com page is accessed, the client is redirected to the appropriate .net URL
E-mail services would need a different list of things to take care of... and so would need any other service whose operation is based on the FQDN. So you see... it is hard to give any concise recommendation. Each service needs to be taken care of individually.
One recommendation, though: the .net can be created for you independently of the .com existence. Initially, it should contain the same set of records as the current .com domain, understandably converted to the .net version. All your services should be reconfigured to accept both .com and .net names and provide identical services. After initially the .net is tested and verified to work, the services should be configured to redirect clients to the .net version of names, if such option exists - in any case, a way to seamlessly migrate all clients from .com to .net domain should be planned and implemented. After the clients are using the .net version and a sufficient time for graceful migration, the .com domain should be brought down but not deconfigured from your devices. Only after the .com domain has been nonexistent for another graceful period (say, two weeks or a month) and the logs on the services show no more accesses to the .com version of your domain, the .com configuration can be completely removed.
Best regards,
Peter
