Site Migration Tasks

Web Site Migration Tasks

December 28, 2013
Scotty Gammenthaler

There has been a lot of confusion and incomplete information about what is required to complete our website migration from the Cyberteams server to our new GreenGeeks hosting service based on Drupal.  This article attempts to list all of the major tasks that are required and show the order in which they must be done to avoid being down during the transition.  This article does not consider other desired features beyond the webserver migration.

Old Configuration:

The Moon Society used a single domain name - - for all web services.  Two servers were running on this domain - (port 80) and (port 443).  The HTTP server delivers most of the web content, while the HTTPS server hosts the online registration system and backoffice utilities for the registration system.  Some features of the web sites critically depend on WebSite Director and Team Director as discussed in greater detail below.

Current Configuration:

Initially, a new domain - - was created on GreenGeeks to support development of the new site.  The original intent was that this domain would remain as a testbed while a new domain would be created for the "live" server.  A second new domain - - was created as the initial live server with the intent that the domain name would later be changed to  A redirect was put in place on the original such that any access to the home page would redirect to as a temporary way of making the new site "live".  It was discovered that some of the links on the www2 domain were hard-coded to point to, creating a problem with splitting and into separate installations, and at present both domains access the same content.  Meanwhile, the  HTTPS content is still served by the original CyberTeams server, and all access to except for the home page is still handled by the CyberTeams server.

Issues That Must Be Resolved:

  1. The HTTPS server requires intimate interaction with Team Director (to access and update membership records maintained in Team Director).  While a complete migration of both the HTTPS server and Team Director is feasible, this requires considerable additional work and it is proposed to initially leave the HTTPS server running on the original CyberTeams server.  Accomplishing this requires that the HTTP and HTTPS servers must be on different domains and it is proposed to create a new domain - - for the HTTPS server.  This will faciitate immediate needs and also provide better management and scalability going forward.  Because the SSL certificate for this server is domain-specific, a new SSL certificate will be required.  (Dana Carson verifies that he has obtained a new certificate.)
  2. We feel that we need domains for testing changes and also for the "live" site.  We must either fix the hard-coded links to on or else create a new domain for the test server (I believe has been proposed for this domain if we follow this path).  Fixing the links problem is the cleaner way of resolving this problem, but at the moment there does not seem to be a simple way of identifying all of these.  (We could point the to a temporary installation that will send an email to the web team showing the REFERER variable from the request.  This would eventually expose all of the incorrectly coded links, but would cause some non-functionality until the problems are fixed.)
  3. We would like to keep the existing online (running on the CyberTeams server) with a new domain name - has been proposed.  This permits ready access to old content in case we overlook something that should be migrated or if someone needs access to outdated material that was not migrated.  This poses some problems - the existing site also has hard-coded links that will break if the site name is changed.  Some work has been done on this but a lot remains.  This is not a show stopper - these can be fixed as needed going forward.
  4. There are other issues on the HTTP server relating to access to members-only and team repository data that require interaction with Team Director.  The best way of addressing these is to migrate Team Director to our new server.  Since we have not started this process, we don't know what difficulties we may run into and this problem will be set aside for now.  (An alternative is to access Team Director on the CyberTeams server through its web interface instead of as a local command-line utility.  This will require finding every such interface and recoding it for web access.)  Another minor issue is that WebSite Director currently maintains index pages for some content - notably the MMM download area.  We will need to find a workaround for this on the new site.

Migration Tasks To Reach New Configuration:

The following are listed in the order in which they should be done to minimize disruption of service.  In some cases the order is non-critical and if you feel a different order better serves our purposes, please contact the web team for guidance.

  1. Migrate content to  The ordering of this task is non-critical in relation to tasks 2 - 5.  This task should be completed before beginning task 6.  A difficulty in doing this task is there is not a concise list of pages that need to be migrated.  The www site has a lot of "dead" pages that don't need to be migrated, and other content that is so outdated that migration may not be appropriate.
  2. Create a new domain name - - pointed to the CyberTeams server and configure the server to accept HTTPS requests for this domain.  (Only Randall Severy can accomplish this.)  This must include installation of the new SSL certificate for this domain.
  3. Copy all existing content for to the new web space.  Test this installation to find any issues resulting from the migration.  When we are satisfied that the new installation is working properly, change any links pointing to the old domain to point to the new domain.  This may require work on both and  This work is not difficult except for being sure we've found all of the links.  (I suggest running a recursive grep for "https" on the www site.  Hopefully the web team will know where such links exist on the www2 site since grep can't be used for pages served by Drupal.  It may be possible to run a search on the database under Drupal to find the links.)
  4. Reconfigure the server to present a "Page Not Found" (404) error for any access to the server and send an email showing the REFERER variable from the request.  This will allow us to find and fix any accesses to the old server we may have missed.
  5. Either fix the links hard coded to on or create a new domain and set up the GreenGeeks installation to server this as a separate domain.  In the following, this will be referred to as the "test domain".  If a new domain is created, only Randall Severy can set up the DNS for it.
  6. Clone the content to the test domain.  Note that tasks  This is not a straightforward task since much of the content is in a database and the www2 database content must be exported and imported into the test domain database.  Note that creating a separate database for the test domain is optional, but I believe the intent of the test domain will not be met if the live and test domains share the same database.  (Changes made on the test domain will immediately be inherited by the live domain if they share the same database.)
  7. Change the server for to the GreenGeeks server.  Change the domain for the CyberTeams server to  (Only Randall Severy can accomplish this.)  Tasks 2 - 6 MUST be completed before task 7.
  8. At this point, a stable server configuration is up and running.  Additional desirable but non-critical tasks are:
  • Move Team Director to the GreenGeeks server.
  • Move the HTTPS content to the GreenGeeks server and shut down the CyberTeams HTTPS server.
  • Figure out how to tie the Drupal access control and roles systems to the Team Director database.