Recently I was working with a client that had hastily built a website utilising the Magento content management system (CMS).
(Magento is an open source platform currently owned by eBay and used by 34 of the top 500 online retailers and powers 26% of all e-commerce sites in the Alexa top million sites).
The company that had “developed” the website had actually in turn offshored the whole development of the site to a group of Asian developers. The website had not been well scoped, and there was no or little documentation provided other than providing the developers with graphical designs of each of the key pages of the website and a brief to replicate the functionality on the existing squeaky website.
The website was being hosted by a reputable host and the company that owned the website maintained control of the accessibility to the backend of the website, much to the chagrin of the developers. The site was consistently slow and plagued by integration and teething problems. Requests to the developers and integrators to resolve issues were not addressed efficiently or expediently, and in some instances at all.
One Thursday morning the developers released some new code onto the site to improve the speed of the site and prevent images from loading until the user scrolled down. The idea here was to take the load off the server and speed up the user experience.
As the day progressed, the sight got slower and slower. Frustrated, the general manager decided to reboot the server remotely. The site rebooted and loaded up and began to perform exceptionally well, probably better than it had ever performed.
Suddenly, a while later, the shopping cart went to error status and shortly thereafter the site fell over and a Magento error page appeared to all who arrived at the site. I happened to be onsite at this client that day and I was drawn in to facilitate the recovery of this website, and this is where things got interesting.
It was around 10am and there was no resource to turn to as the offshore developers only came online around 12.30pm AEST.
In the meantime we approached the hosting company via their helpdesk to inquire whether they could assist and advise if the problem was server or software related. They immediately began to investigate and came back with some suggestions relating to problems with the database.
By this time the offshore team was now online and fervently trying to troubleshoot the problem. They acknowledged that the MySQL database was not starting. The integrator/web developer was suggesting that our reboot had caused this failure and was pointing fingers at us for the failure. As the day progressed chances of recovery were becoming less and less of a reality, with no progress being made.
Late that night the offshore project manager came back to me and suggested that they didn’t know what to do and wanted some direction from me. This rang serious alarm bells. At the same time the engineers at the host had responded that they had found a major database problem and that they would work on it and if they could fix it, the site would be up and running in the early hours of the morning.
At 6am I visited the site to find it was still down. It was time to call in some favours. I contacted a professional, reputable Magento development team in New Zealand, it was 8am there and the timing was perfect for them to get onto the case immediately.
They spent approximately 20 minutes on the site and advised that it would be better and quicker to do a fresh install on a new trusted hosting environment. Troubleshooting and rectifying could take hours if not days without guarantee of a successful recovery. A copy of the website and database were transferred to them in New Zealand and they began the process of creating a new migration.
By 7pm that evening, a fresh new working website had been installed on a clean hosting environment. The developers found multiple problems with the current site and provided a list of recommendations and fixes that needed to be implemented.
As interesting and hair-raising as this experience was, I share it to highlight some very important factors that should be considered by all businesses that rely on their website to generate income. Incidentally, this retailer lost tens of thousands of dollars in turnover, not to mention the damage in reputation to those that visited the site and the damage it did to Google’s rankings.
Don’t believe me? See what Dan Petrovic from Dejan SEO has to say about this.
What are your organisation’s disaster recovery plans for your website? Do you have one? What is your relationship with your host and your developers? Once again do you have one?
Some key points you need to take from this:
An e-commerce website is not a set-and-forget piece of technology.
You need a relationship with your developer that extends beyond the completion of the website as per the initial scoping document or agreement you have with your web developer. This could exist in the form of a maintenance agreement or maintenance hours purchased per month, or an agreement with the developer whereby they will charge an hourly fee if and when needed.
What about hosting and server support?
Often after a massive website failure, website owners are horrified when their web developer explains to them that they (the web developer) are only responsible for the site, not the hosting and they can do nothing to help as they are not responsible for backups, the database etc.
The website and hosting are different things. Think of the website as the patient and the host as the hospital. The doctor takes care of the patient (website) and the hospital (host) provides the bed, operating theatre, nursing staff, etc. If the food is bad, it’s not your consulting doctor’s problem but the hospital’s.
Get my drift? Do not expect your web developer or your host to make and keep current backups of your site unless you have already agreed to this in some form of written contract.
Don’t wait for a disaster to discover that you may be offline for weeks or months or potentially go out of business if no backup or redundancy exists.
Many web developers offer hosting and website technical support as part of a monthly package; however, like anything else, caveat emptor – buyer beware.
There are fully hosted solutions that manage the complete website and server management and I recommend these for small businesses that have budget restrictions. Local solutions such as Neto offer turnkey solutions for very reasonable setup fees with monthly ongoing fees starting at around $100 for a fully transacting website including hosting, etc.
Another great solution is eCorner Stores. Bigcommerce or Shopify are other options, however, they do not offer a person-to-person relationship, and their services are based on an online subscription model whereby you log in, punch in credit card details and start building your site. Most support is by email ticketing.
The barriers to entry in setting up an online store are very low. However, once you are up and running there are considerations that must be taken into account. Just as you take out insurance to protect your car or business, steps need to be taken to protect your cash-generating asset, your website.
Mark Freidin is an experienced chief operating officer, e-commerce pioneer and consultant to fast-growing firms with his company internetretailing.com.au.
Mark Freidin is an experienced chief operating officer, e-commerce pioneer and consultant to fast-growing firms with his company internetretailing.com.au.
