Moved Server & Notification URLs Are Not Working

[organic]

We just moved our site to a new server last night. We changed our name servers at our registrar about 24 hours ago. Throughout the day, we've had instances of the old site showing in browsers, emails going to the old server, etc.



One of the most persistent issues we've had is a script we use to catch data from E-Junkie notification URLs and write it to a database. It does not work on the new site and new database. I checked the database on the old server, and the data is appearing there, so it appears E-Junkie is sending the data to that old server (where the old site and database are still setup). I assume this is because E-Junkie's DNS servers still have the old name servers.



Our last transaction went through about three hours ago, and it's still being sent to the old server. Am I correct in assuming this is a DNS issue? Is there anything that can be done about it?

[E-junkie_Guru]

That does indeed sound like our DNS reference is still pointing us to your old server's IP; I will bring this up with Operations to see if we can force an update to our DNS cache for you. :^)

[ellen]

I just checked from a good sample of our various servers in different places, and they're all seeing a consistent picture:



* your registrar data "Last Updated on: 22-Feb-11" (i.e. looks like the new data)

* domain servers DNS1.VPS.NET and DNS2.VPS.NET

* www.organicthemes.com resolves to 98.158.187.249



Assuming that's all correct, is it possible that your script which receives the notifications still has the IP address of the old database hardcoded, and it's connecting back to it?

[organic]

Thanks guys. That is correct. I believe the servers must have finally updated about 6 or 7 hours after I wrote the initial post, because the script is now receiving data from E-Junkie. We are also receiving emails from E-Junkie regularly.



I think everything is fine. I'm guessing it just takes a little longer than 24 hours for all your servers to update. Thanks for your help again guys.

[E-junkie_Guru]

Ah yes, since it appears that you'd changed your DNS host as well as changing the IP your domain resolves to according to that host (vs. where your old DNS was pointing your domain), it would have taken up to 48 hours for that DNS-hosting change to propagate 'Net-wide, though we just forced an update in our own DNS manually to make that happen for us now. FWIW, the better way to do it would have been updating both your old and new DNS hosts with the new IP for your domain, and then make the switch saying which DNS host should act as the authority resolving your domain.

[organic]

Interesting. Thanks for that info. I was thinking there must have been a better way of doing it.



So, our site used to be hosted on Media Temple. The new one is at VPS.net. Our domain is with GoDaddy. Let me see if I understand. I should have updated our DNS zone at Media Temple, telling it to point to the new server IP. I also should have setup the DNS zone info at VPS.net - then I should have changed the nameservers at GoDaddy? Do I have that right?



In effect, that would have almost instantly pointed all users to the new server via Media Temple's DNS zone info. Then DNS servers worldwide would have slowly picked up the nameserver change from GoDaddy; but no one would know, because they would already be reaching the new site. Am I understanding it correctly?



This is very valuable info. Thanks again.

[ellen]

You've got the gist of it correct, yes. Your change will be "almost instantly" propagated within the constraint of whatever the TTL on your host record was before the change, but it's almost certainly way lower than the standard 48-hour TTL on the records that your registrar pushes to the root servers. For example, right now your host records have a TTL of 900 (seconds, = 15 mins).



You should have the right to point any resource that's legitimately under your control, to any other resource that's similarly yours. Whether mt actually honors that for their DNS service, I couldn't say; I'm a fan of using a 3rd-party DNS service (neither part of your registrar nor your hosting provider) to avoid that kind of problem, among others.

[organic]

Great info. Thank you so much. I did not know about the intricacies of DNS. It's been 48 hours now, so I think we're out of the woods; but I will certainly head your advice on the the next move we make.



Thanks again.

[dw27]

We are needing similar guidance... I will be migrating from GoDaddy shared server to a grid server and am wondering what i can do to have a smooth uninterrupted process. I would appreciate any handholding you can provide.



What do you need to know in order to help me?



NOTE: in order to move existing working site to a grid server, I have to enable SSH, so i will be doing that. 1st "migration". Then i upgrade to Grid server. 2nd "migration".



I guess I will need to know what e-junkie settings I will need to reset, redirect to remain functional.



Thanks for your help.

[E-junkie_Guru]

E-junkie does not depend on your site being located on any particular server or domain, so your cart button codes should continue working fine in your pages at both the old location and the new one without having to change any settings or code.



If you happen to be using our custom/3rd-party Integration feature (Common Notification URL or Payment Variable Information URLs) to send order data to some script(s) on your server, you should make sure those scripts are set up and functional on the new server before you repoint your domain name's DNS record to the new site server's IP.



If you will also be changing your domain's DNS host, then as I explained above, first repoint your domain to the new server IP on both your old and new DNS hosts, and then you can update your domain registration to reference the new DNS host.