Moving to a new domain from an old domain – Problem Solving

computer programmer

I am continually impressed and grateful for our team. The leader of our webdesign engineering team wrote this how-to document/story describing his journey of moving to a new domain for a client’s website. He wrote it for our internal records, but it was too helpful to keep in-house. How often do you get the opportunity to explore the brain of an engineer in problem-solving mode? I hope you find this very useful and a little bit entertaining. 

Recently we created a website for a client. Their old domain and website was something like domainextrastuff.com. In the process of creating their site, we found out that their new domain, according to the storyline, was domain.com, and that domain was sitting idle.

So, we convinced them moving to a new domain was the right thing to do.

All good until we got to the nuts and bolts. 

  1. We had to accommodate all old links to the new address.
  2. If someone typed in deomainextrastuff.com, it had to go to the new domain.
  3. If someone typed in http://domainextrastuff.com, it had to go to the new domain.
  4. All forms of the new links had to point to the new domain.

The last bullet was easy.

As we talked to the domain registrar, they said no problem. You should be able to use the forward right in the domain registrars interface, and it should work fine.

To make a long story short, 2, 3, and 4 all worked well. Frankly, we probably wouldn’t have noticed it (but people in the real world would have…sigh) unless one of our teammates had a built-in link for wp-admin that was fully qualified to SSL.

The problem would come and go. We thought we had it fixed. One of my development team members spent nearly 2 hours working with the domain registrar to help staff troubleshoot moving to a new domain.

I finally decided to get online with the domain registrar, thinking I would probably have to remove the forward (which wasn’t working) and do an alternative. While I had to wait 17 minutes to talk, the lady on the other end was amazing.

I explained the situation to her. She said something like I’ll have to dig into this. It is strange. Then about 30 seconds later, she was back. I’m sorry, sir, this forwarding thing won’t work. I’m thinking that was really fast.  

Then she said, “I’m sorry, sir, you have to have an SSL certificate on the domain for the https link to work.

So we discussed some alternatives.

I ended up:

  1. I made sure we had a new host for domainextrastuff.com.
    1. Changed the dns pointers at the domain registrar to the hosting location (@, * and domain).
  2. Requested an SSL for domainextrastuff.com
  3. Under the cPanel, in the domain section, there is a Redirect.
    1. Pointed current domain (domainextrastuff.com) to domain.com

And it worked!

All the old domain pointers and names will get to the new site. We didn’t need anything other than the SSL on the old domain.  

To the psychological state here, let me say we got into a very unhealthy state as IT folks. It is not only me and my team but teams from one of my hosting companies and the domain registrar. I, my team, and my extended team all started troubleshooting and putting bandaids on the problem. Our client’s address wasn’t working—emergency mode. Turn off your brain and find something to make it work mode.

Instead, we should do what engineers do best—cause analysis. Go back to the core. Somethings got to be broken.

In this day and age, most things come down to core principles and how we break on them. Part of the IT person’s job is to take a step back and look at what principles are being broken and what they really need to break.

In this case, we were asking for an SSL to an unhosted domain. It is without foundation. As my friends in Germany would say. Forbidden. That is breaking a core principle.  

The resolution was 3 simple steps, taking a total of a few minutes.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email