In preparation for exciting announcements about Instructional Technology at Reclaim Hosting, I thought it was finally time to consolidate past workshop event sites. If tinkering around on the web has taught me anything, it’s that if you’re not careful about how you are setting up digital projects from the start, they’ll come back to haunt you later in life. (Sort of like the Ghost of Digital Presence event poster, haha!) A series of one-off decisions & repeating workshop events over the years all culminated to a single moment last week where I was left looking at this:
I had essentially duplicated a new WordPress site for every Roadshow workshop event since 2018ish, and as you can see, they were all out of date. Certainly not a sustainable choice, but it worked for me at the time. However now Reclaim is moving into a fresh era where workshop events & materials will become much more consistent and readily available, so my site structures needed to get with the times, too.
Given these are simple WordPress sites, I could’ve flattened them into static html pretty easily, but two things stopped me:
Personally, I really prefer having the Installatron user interface be an accurate representation of what’s in my File Manager
The site designs were nothing to write home about. I was just interested in preserving the event itineraries and internal data about event attendees.
Because of the above, it made more sense for me to export any registrant data to store and use separately, and then to bring an archive of previous event itineraries into the fold of one main event site: roadshow.reclaimhosting.com/events. For each site that I wanted to consolidate, I created a single page on the new /events install like roadshow.reclaimhosting.com/events/skidmore.
On each new workshop page like /events/skidmore, I brought over all original event descriptions and images. I then added a Page Break like the one shown in the screenshot above and then subsequently added the event agenda information. After publishing, each new event page look something like this:
In the “pages” section at the bottom, you can now click on Page 2 to see the event agendas:
Once bringing over this information for each site, I copied over all Woo Commerce registration information into a spreadsheet in Google Drive. I also updated the original WordPress installs and took one final Installatron backup:
The final piece of the puzzle here was to redirect traffic from old URLs to new URLs. I did this in cPanel > Domains > Redirects:
Last Summer, Jim and I met with the administrators of BYU domains, Nate Walton, Joe Hadfield, and Jason Renfro and were told that BYU and the Office of IT would be retiring the BYU Domains service at the end of December 2021. Reclaim Hosting has worked very closely with BYU over the last six years to bring Domain of One’s Own onto campus and into classrooms. Over that time, BYU Domains grew to become our largest Domain of One’s Own institution to date with over 14,000 users, all of which received their own Top Level Domain. This is no doubt attributed to the work that Nate, Joe, and Jason have carried out, as well as folks like Peter Sentz and an entire team of student workers and members of OIT have done to support the initiative. It as been insanely cool to watch BYU Domains scale over the years, and Reclaim Hosting is incredibly lucky to have worked with such a fantastic partner while discovering the potential of Domain of One’s Own.
All good things do come to an end, and through this blog post I hope to acknowledge the other side of this job which isn’t commonly addressed: Decommissioning Domain of One’s Own. This post will be a deep dive of this work. After we were told that BYU OIT would be reallocating resources to other services, we immediately began brainstorming ways to make sure that 14 servers’ worth of users would have a seamless transition to whatever came next. That was, and has continued to remain, priority number one.
Phase One: Brainstorming & Prep
Reclaim Hosting has existing migration strategies in place for end users that are looking to move away from Domain of One’s Own. In short, they can grab a backup of their cPanel and take it with them to any number of hosting companies, or they can sign up for a Shared Hosting account at Reclaim Hosting and we’ll migrate their content for free. Over the years, we have carried out hundreds of migrations from graduating BYU students looking to continue hosting their digital projects. While this works on an individual basis we knew that this workflow would not scale; it would overwhelm our support team and it would require work from each user to sign up for an account at Reclaim.
I went to the drawing board two or three times to come up with the best way forward. After multiple brainstorming meetings with Jim, Tim, and the BYU Team, we landed on the following:
Reclaim Hosting would take over all BYU Domains accounts by rebranding existing infrastructure, bringing servers into the Reclaim Shared Hosting fold. Eventually, Reclaim would consolidate active accounts into existing Shared Hosting servers.
My other considerations:
Timelines. We needed to be able to “flip the switch” for end users no later than end of December/beginning of January. We had to consider domain renewal dates at the registrar, new signups at the beginning of the Fall 2021 semester, and time for communication and reminders to users.
Language. Given we were merging the support of two teams (BYU OIT and Reclaim Hosting) it was important to make sure everyone was on the same page about when and what was happening. We also needed to be unified in how it was announced to users in mass email, support tickets, and support documentation.
Infrastructure Configuration. By “adopting” BYU servers and bringing accounts into our Shared Hosting fold, we would have to evaluate the disk usage of all accounts and then assign each account to one of our Shared Hosting plans. Moving away from Single Sign On and into Client Area Portal was also something we had to work through.
Support. By taking over BYU Domains at the end of the year, how would that impact our support ticket numbers? We would need to look to BYU for this one to get a sense of their support analytics, and how that would translate as Reclaim took over ownership.
Edge Cases. Not everyone would fit the mold of our shared hosting plans when it came to storage and/or account resources. Additionally, BYU was looking to carry on funding the hosting costs for larger departmental sites. We had to have a way to “flag” or separate the edge cases from the mix.
Given all the moving parts, I needed a place to manage simultaneous tasks and project milestones, delegate work, keep track of our progress, and stay in constant communication with everyone. Asana became my backbone for all Reclaim Hosting work, and then I stayed in communication with BYU using email, Google Drive, and good ol’ fashioned spreadsheets.
This is a screenshot of the Overview Tab of the Asana Project. Looking back now, its pretty cool to see the timeline on the righthand sidebar: when the project was created all the way through company-wide communication.
Phase Two: Planning and “Flipping the Switch”
This is where the real work began! That summer we asked BYU Admins to begin culling through all existing accounts and clear out/remove anyone that no longer needed a cPanel account. As with any DoOO Institution, we helped in this case by receiving a .csv of accounts to be removed, backing up their accounts one last time, and then terminating them in bulk. Through this process, we were able to consolidate 14 servers down into 10 servers. Getting rid of the fluff was the first step in preparing for the changeover to Reclaim.
Next, we decided on “End of Life” Timeline. Here is a rough outline of what worked for both teams:
Sept 1 – Nov 1: BYU to communicate changes to entire community
Sept 15 – Nov 15: Flag all byu.edu domains “edge cases”
Oct 1: Turning off new signups
Nov 1: Have all email templates, support macros & documentation drafted to review with BYU Admins
Nov 15: Make changes to language as needed
Dec 1: Reclaim’s voice introduced in a “Here’s what’s coming” email
Dec 20: Publish Support Articles
Dec 27-31: Rebrand infrastructure/logins to Reclaim Hosting
Jan 3: Generate Invoices, Generate passwords, Send an Account welcome email to all users
Jan 3 – Feb 3: Tackle incoming support requests
Jan 27 – Feb 2: Invoice Reminder emails
Feb 3: Suspend unpaid accounts, notify users
Feb 3 – March 3: Tackle incoming Support Requests around suspended sites
Feb 7-11: Tally up list of users that have paid after initial 30 days, plan for system migrations in the new year
Feb 25: Account Pending Termination email
Mar 3: Backup and terminate suspended accounts
Mar 3-31: Tackle Incoming Support Requests around terminated sites, restore as needed
March – May: Server consolidation as needed to migrate active accounts into existing Shared Hosting servers
As you can see from the timeline, the months leading up were more or less about communicating upcoming changes, introducing Reclaim Hosting to BYU Domains users, and making sure our team had a solid game plan for the change of ownership. We got all communication written and approved, notified and prepped the support team for incoming tickets, and made sure Infrastructure had what they needed in order to test out changes and be ready for game time by end of year. As of January 3, we “flipped the switch” and are now in the phase of tackling support requests. This means letting folks adjust to the change, ask questions about what hosting looks like at Reclaim, and understand what their annual invoice will look like going forward. These are support resources available for users as well:
It has been really cool to watch all teams at Reclaim step up and prepare for this project during the various phases, and it gets me stoked for other team projects down the road. Asana also helped a ton by allowing me to delegate work & timelines to various teams as well as specific people. Certain tasks are dependent on other work happening, and Asana is great for tracking that, too. (read: Asana Task Dependencies)
I’m pretty proud of how we’ve been able to stick to this timeline, no matter the circumstances. Ultimately, I think this has been successful because we set realistic milestones and added flex space in between tasks for unforeseen situations to arise. Planning for the unknown and being flexible to change is a crucial part of keeping large projects afloat. While we are now over the bulk of the work (i.e. rebranding, taking over ownership) the project will still likely carry into early summer as we undergo multiple rounds of server consolidation after active account numbers are reassessed. Even still, this is a great time to press the pause button and celebrate the work done thus far.
I’ve especially enjoyed working closely with Chris in Infrastructure as he has played a key role in configuring the server(s) for this change, and his way of finding solutions for seemingly impossible tasks is always amazing to watch play out. A lot of my role in this project was saying, “Hey Chris, what happens to SSO?” knowing that something would have to change to about the way folks were logging in, but having no clue how to make it from point A to point B.
At some point I’d love to sit down with him and reflect about how everything was handled, think of things we may have done differently now knowing what we know, etc. but overall big kudos to Chris for his management of infrastructure tasks.
Now as I reach the end of my reflection, it simply would not be complete without mentioning the absolute day-maker that happened at the end of the year:
Receiving a handwritten thank-you note from Joe was so appreciated, and a cherry on top to this project. No, BYU Domains- Thank YOU!
I’m headed to Stanford University’s campus tomorrow morning to begin a two-day chat with a variety of authors, digital preservationists, and technologists to strategize and formulate tangible gameplans for preserving and archiving digital projects. Everyone in attendance will be bringing a different perspective to the table, and I’m very much looking forward to the conversations that will flourish. I thought I might take a quick moment to blog a summary of my perspective, as I’ll be sharing it briefly tomorrow afternoon.
Reclaim Hosting was founded in 2013 as a way to provide affordable web hosting space for individuals and educational institutions alike. We’re set apart from the Wix’s and Squarespace’s because we encourage digital literacy and growth both in and outside of the classroom. Our support tickets go deeper than resetting passwords; we teach, advise, and converse with our customers about the tools available to them. In addition to fixing the problem at hand, we use these support tickets as a learning experience for the inquirer and provide the steps we took towards the solution so they might be able to do fix it themselves it in the future. For the last five years, supporting customers has been the very top priority for Reclaim Hosting. We keep out reply times lightning fast, our satisfactory ratings high, and regularly put answering support tickets before all other projects.
It’s important I share Reclaim Hosting’s priorities from the very beginning in order to show how they have adapted, changed, and grown, even in the last three years since I joined Reclaim Hosting in 2015. While we still place the utmost importance on our support, our growing team and comfortabilityÂ with the infrastructure have allowed us to shift focus towards the future, but also towards preserving the past. Will we use cPanel forever? What will be the next ‘WordPress’? These are just a few of the many questions that have been floating through my mind, at least, especially over the last year or so. What’s more, Jim and Tim recently gave a talk at OER18 about Cloudron as a potential path for our future beyond the LAMP environment.
Technologies and softwares are always updating and advancing, and Reclaim Hosting obviously wants to provide the most relevant, up-to-date tools for users. But how do we do that while also hosting and preserving work that has been created on tools that are maybe no longer supporting themselves? Here’s another scenario: Reclaim now has institutions that have been with us for a couple of years and are racking up quite a bit of content from their community. How do they preserve the work of students and faculty members that are no longer institution?Â These are the golden questions, I suppose, and likely ones that will be thrown around quite a bit in some form or another over the next few days.
While the answers are hardly black and white, we’ve already begun to address some of this in the form of migration strategies and site archive utilities. At the root, however, we believe that in order to make digital projects sustainable, we must make them portable and transferable so they are not restricted to the platform where they were created.
As an example, Tim began creating a Site Archive Utility plugin in cPanel that would allow the user to input their site URL, click import, and archive their site as static HTML on the server (essentially doing the work of something like SiteSucker.) The idea here is that you could do things like schedule archives, store them on a third-party service like Amazon S3, save them locally in a specific folder of your choosing.
But in the spirit of strategizing with others at the workshop, I think it would be incredibly fascinating to have the ^above feature on our Migration Assistance page for Domain of One’s Own schools, for instance. A student would be able to import their site as static HTML, but instead of saving locally or on S3, the files went to an actual archiving service. And, hypothetically, that archiving service would have a small corner of the internet dedicated specifically to specific institutions. Those schools would then be able to use that as a resource for work that they’re interested in keeping long-term in addition to the tools provided at Reclaim Hosting. But that’s just an idea. :)
It’s hardly news at this point, but Reclaim Hosting isn’t doing a Domains conference this year. We loved Domains 17 (and are currently mulling over a Domains 19) but we deemed 2018 as a gap year a couple months back. This has meant that the conference website, domains.reclaimhosting.com, was just sort of sitting there with content that is now close to a year old. I was also growing rather tired of logging in every now and then and making sure all plugins, themes, and softwares were up to date. What’s even more, the Domains17 site was sitting on domains.reclaimhosting.com, meaning if we were having a Domains19, things would obviously need to be shuffled around.
On an unrelated (or is it?) note, I’m headed to California in a couple of weeks to take part in Stanford University’s Preservation Workshop to chat about archiving digital projects and possible strategic partnerships with preservationists and technologists. So to say the least, I’ve had archiving on the brain over the last week or so. As part of my preparation for the workshop, I’ve been wanting to play around with and explore some of the digital archiving tools that are already out there. Though I’ve recommended SiteSucker to many Reclaim users in the past, I’ve never given myself the chance to play it. So between this workshop and the Domains17 site, I thought there would be no better time than the present to get going:
I started first by making the subdomain, domains17.reclaimhosting.com, and then added it as an AddOn domain to the cPanel account where the current conference site resided.
^I then cloned the original conference website from domains.reclaimhosting.com to domains17.reclaimhosting.com using this method.
After confirming that the site was completely up to date and loading securely on the new domain, I opened up the SiteSucker MacOS app that I had previously downloaded. (It’s $4.99 in the App Store, fyi. Kind of a bummer, but I imagine if you do some serious archiving you’d make your money back rather quickly with the amount of time you save. It’s lightning fast.)
^Screenshot of what the SiteSucker window looked like while it was working.
I simply entered the URL and pressed enter. Within two minutes it was done! I pressed the folder icon (top bar, middle) and could immediately see all the WordPress site files that had been translated to Static HTML. Once having the files on my local hard drive, I closed out of SiteSucker and opened up my FTP client. (My personal favorite is Cyberduck.)
I navigated to the domains17.reclaimhosting.com directory, removed the existing cloned WordPress files, and uploaded my new static HTML files.
I refreshed my browser and boom! The site now loads beautifully (and quickly!) over HTML only. I had an issue with one of my visual builder buttons still linking back to the old domain, but that was an easy fix. I used Chrome’s inspect feature to figure out where the link was located in the code and then used the command+find tool to fix it in my File Manager.
As my final step of maintenance cleaning, I created a redirect so that all visits to domains.reclaimhosting.com be redirected to domains17.reclaimhosting.com for time being. This way I can begin to alter the content that currently sits at domains.reclaimhosting.com, while simultaneously familiarizing visitors with the new domain.
From start to finish, this took less than ten minutes complete. Not a bad for a little afternoon project. I’m excited to continue playing around with Sitesucker, but very impressed so far.