As I’m currently still playing catch up at the day job plus doing about a million things IRL (don’t ask!), We have a guest post by Joe Shoop about the importance of picking the right systems when migrating or building your site and the problems that can and will arise if you don’t! I’ll be back in two weeks with another update!
One of the greater pleasures of working in the online space today is that there are few ways to go “wrong” with your site’s configuration and setup. While it is most certainly possible, even a few critical decisions made early on can be undone and corrected with a little bit of work.
The key word is ‘most’.
There are still some configurations that will cause numerous headaches, have difficulty working together, and have you searching to the ends of the earth for support and assistance. There are still some ways to build and maintain websites that can cause more grief than good, especially when considering your marketing outreach and interfacing with third-party applications. While you may enjoy the challenge of using unproven technologies or rarely-seen CMSs, but these could cost you dearly in the long run, either in costly redevelopment costs or missed opportunities.
Case in point: I recently began working with a medium-sized client who was having difficulty with a site migration. Their organization had been working with a severely outdated site – one in which they still – in 2019 mind you – still had no mobile-friendly version. Not only that, their existing site had no discernible way of offering canonicals, meta descriptions, and all asset styling had to be done on the page; there was no access to the CSS files!
For all of these clear disqualifiers, the site did have some advantages which had prompted the group to keep the site longer than they should have. Among them, seamless eCommerce integration, reasonably quick loading times, and easy page alias configuration. But with more and more possible traffic being left off from mobile devices, they made the decision to migrate to a new platform.
Issue #1: Lack of Knowledge of Modern Web Technologies
A CMS. Built with C#.
While this in-and-of-itself isn’t the worst idea, can any of you think of a widely-used, well-known content management system built in C#? Yeah, me neither. It makes me think of building a lawnmower that runs off of plutonium – it could work, but it’s a little unnecessary.
They talked to several different CMS providers, and ultimately decided on a CMS called [CMS redacted]. While this CMS is perfectly fine, there’s nothing particularly impressive; it’s just a CMS built with .NET.
Issue #2: Incompatible Technologies
While deliberating the choice of CMS, they made a very quick decision to use [database redacted] as their new database management software. This was a decent choice, as [database redacted] is arguably the industry leader, offering lots of support, a passionate group of enthusiastic fans, and developers everywhere that can help make everything run smoothly.
However, due to the specific nature of this business, they needed some extras baked into [database redacted] to handle all of their specific eCommerce needs. There were alternatives in the marketplace that may have been better-suited to meet their needs right out of the box, but they were determined to use [database redacted].
So, now faced with a virtually unknown CMS and an imperfect database system, they began seeking ways to make them work together. Unfortunately, they quickly found out that there was no plugin or other out-of-the-box solution. They were going to have to find a contractor or another service to force it all to work right.
Dear reader, this should be a clue that you’re beginning to make bad decisions – your website shouldn’t require that much forcing to work. While you may have to do some configurations, of course, you shouldn’t have to go to extremes to make this configuration come alive.
Issue #3: Lack of Professional Support
After an extensive search, they found one vendor (ONE!) that said they could offer everything they needed and make it all work beautifully in concert. Eagerly, my client agreed to use their solution to work with [database redacted] and work with [CMS redacted] to make all of the ins and outs come together.
Additionally, they hired another contractor to handle the web build. While their in-house developers could handle the build, they wanted to focus on other projects and let the experts handle the web project.
Six months into their web build, they found out that the web developers had done practically nothing, and the database team had greatly overstated their capabilities, and would only be able to deliver on about half of the agreed-upon work.
At this point, after thousands of dollars spent and numerous hours wasted, the web launch team should have reconvened and began looking to new solutions. As a web professional, it was clear that the chosen configuration wasn’t working, and reassessing their original decisions should have been their next step.
This wasn’t when I was called in, though. They decided to press on.
They managed to find only one other reputable web development company that could support [CMS redacted] and would be willing to take on this project. As for the [database redacted] solution, they found a couple of different solutions to bridge the gap.
For those scoring at home, we’re now up to four different vendors supporting this website, with only one vendor being dismissed.
Issue 4: Assuming the Structure of Your Organization Will Not Change
A funny thing began to happen to my poor client around month ten of the site migration – the two developers in the IT department both found new opportunities at left the company within months of each other. This now left very few people within the department to offer support for either the old or the new site, and no one remaining knew anything about .NET development. Not only did this make the decision to go with [CMS redacted] irrelevant, they left the company with numerous ASP.NET on-the-fly solutions that no one can maintain and very little documentation to help new members make the connections. They could hire a new developer internally, but finding a qualified developer willing to work for a smaller company, maintaining a website and unravelling undocumented code hasn’t produced many qualified applicants.
As if this wasn’t enough, the [database redacted] third-party development team that had already welched on half of their original promises now came back to my clients stating that they wouldn’t be able to deliver even more of the original agreement. The team had to find even more developers to help make this companies “solution” work for their website.
At this point, the web team should have seen the writing on the wall. With all of the money spent, contractors coming and going, and still a long way from a new site, they should have taken a step back and reconsidered the path chosen. This is not what happened; they decided to move forward.
This is when I was brought in.
The Bottom Line
I wish I could tell you that the story ended well. I wish I could say that the team came to their senses, realized that some of their early decisions were causing more trouble than they were worth, and could manage to shake the sunk-cost anchor around their necks, but this is not the case.
I’ve been assisting this client for nearly a year, and we still haven’t launched this albatross. The store is being delivered by four different technologies, and we haven’t even seen one completed store page on the site. We’ve migrated the content, but we’ve spent numerous hours with our development team creating display solutions from scratch that I personally know I could have installed a WP plugin and had a free solution working in an afternoon. On top of this, we’ve added at least three other vendors to provide additional functionality to make this CMS give us the same kind of functionality others offer out of the box.
For those scoring at home, that’s eight (EIGHT!!) different vendors we’re currently working with. And in a couple more months, this site migration will turn two years old. And we still don’t have a site ready.
The team is in too deep. There’s no going back. And worst of all, the enthusiasm for the site is all gone. So many concessions have been made along the way, and so many desired features have been pushed back to “phase II” that the new site is arguably worse than the one they had. The team is exhausted, burned-out, and look forward to launching the new site only to be able to move on to new projects.
Meanwhile, the vendors’ invoices keep coming, the conference calls keep escalating, and the site launch date just keeps going further into the distance.
So, what’s the point of this story? Don’t be afraid to step back early and often to assess the technology you’re using, whether you’re migrating a site or maintaining your current site. Unless you’re confident in your abilities, you probably want to rely on industry-leaders for all of your site technologies, and never trust unknown solutions for mission-critical assets. Check around, and make sure you can reach out to someone else for help if you ever need it. Finally, figure out exactly what you need for your site, and make decisions accordingly.
Or else you’ll risk getting stuck in website purgatory, like my poor client.