How to Avoid the Prevalent Pitfalls of Deploying an Enterprise Website

As times change, new devices emerge and browsing patterns evolve, it's never too long before your large scale enterprise website is in need of yet another complete revamp and relaunch. 

Website deployment is by no means an easy task for any enterprise. Fortunately though, Magnolia are seasoned experts when it comes to such projects. Whether the challenges come in the form of training or retraining developers to manage the task at hand, or migrating huge sections of existing content, Magnolia have been there, and done that.

The pitfalls of deploying an enterprise website are many, and failing to avoid the unnecessary risks whilst managing the necessary ones can have seriously adverse consequences – sometimes at the expense of the entire project. 

So, to help you and your enterprise approach your website deployment in the smartest and safest way, here are some highly effective strategies derived from just some of the points within Magnolia's information-rich white paper.

Understand Content Migration Time

Migrating existing content when re-deploying your enterprise website has immense benefits. Regular visitors of the website will remain engaged post-launch thanks to the familiar content, whilst content migration also does wonders for maintaining your website's search engine rankings. 

However, the process is multi-layered, requiring a watchful eye, and most importantly, time. 

It is vital to understand that when carrying out a content migration process, it is not just page content that needs to be migrated. CSS, JavaScript, page templates, images and media files all need to be accounted for, with each of these different elements requiring a range of tools and differing amounts of time to successfully process and migrate.

For example, a web-scraping tool might be able to migrate the content of a single page in a few seconds, but this would not be representative of the time required to transfer other resource types. Images might need to be resized or reformatted to fit the new page templates and so take significantly longer to be migrated. You also need to factor in time to manually check and validate each page, to make sure it's been properly migrated and doesn’t break when rendering.

Also, it's worth noting that the code captured by web-scraping tools does not transfer variation functionality. This includes things like geolocation and personalization parameters, which may need to be re-configured or re-written altogether prior to the launch of the new website.

Avoiding resource duplication is another potential issue. In many cases, the same resource might be referenced from multiple website pages. If your migration tool isn't intelligent enough to detect this, you'll end up with multiple copies of the resource in your asset library. Cleaning up these duplicates is a time-consuming manual process, which will only be further compounded if your asset library is on the large side.

Construct & Stick to a Solid Post-launch Plan

Deploying a revamped website requires more than just a short-term event. You'll need to piece together an actionable, manageable post-launch plan to cover future additions and other aspects.

After all, it won't be too long before bugs need fixing, new features need adding and pages need updating. Hence, your post-launch plan should include processes for website backup, restore and upgrade.

When it comes to defining a backup schedule, ask yourself the question, “If a website failure occurs right now, how many hours of data can be lost without a critical impact on the business? A week? A day? An hour?”. The answer to this question should determine your backup interval. For most companies, a daily backup will usually suffice; however, this depends heavily on the nature of your website. If you have a large team of editors deployed to apply near-constant website updates, you may want to shorten the backup intervals down to just a few hours.

Cloud backups are typically more complex than regular physical server backups, and the shared nature of cloud servers usually means you have to work harder to ensure that your backup contains all your data and only your data. Such checks would need to be made regularly.

Of course, being able to restore backups is equally as important. A common mistake is to perform regular website backups without ever actually testing them. Ensuring that the backups are working on a regular basis is vital, as many factors can come into play to disrupt the process. For example, changes in server infrastructure might render a backup invalid, or a lack of familiarity with the restoration process might result in longer downtimes. As a rule of thumb, schedule backups to occur on at least a monthly basis to avoid problems during a genuine crisis.

When handling website upgrades, you will need separate environments to test the new version of the website before rolling it out to production. Typically, you will first deploy to a development environment with minimal data, then to a test environment with a larger sample of data, and finally to an integration environment which has a full copy of the production data.

This last step will also provide you with a useful hint regarding the amount of time the upgrade will actually take. This allows you to comunicate more consicely with website visitors. Finally, if everything works well, you can backup the current production website with all its data (as a failsafe against unforeseen failures) and then deploy the new website.

Embrace the Change

Change of any type can be hard to adjust to – and that includes enterprising companies. Developing and deploying an enterprise website will not come without elements of internal politics and technical technical issues, so be prepared for some dissent as the impact of website's changes come into effect.

Naturally, this apprehension is primarily linked to the time and money involved in such a large project, along with the potential negative impact on the organization's reputation should the project fail.

So, before embarking on the journey to deployment, you must get all stakeholders and other important parties to agree on the high-level issues. This includes technical and branding requirements, budget, schedule, team and vision. But as work progresses and changes begin to come into effect, expect the lower-level details like icons, fonts, navigation, copy style and so forth to take center stage, as more people to come forward with criticism and feedback.

In the three months prior to launch, comments, feedback and criticism of such elements will reach their peak. In many cases, it will seem as if everybody within the organization has a different, yet increasingly loud opinion. At this stage – and at all other stages, it is important to ensure that this large volume of often-conflicting feedback doesn't derail the project. Establish some ground rules, but maintain the openly communicative progress with all stakeholders, both internal and external. Ask for feedback as needed, but weigh opinions appropriately.

Such feedback from different parties is all part of embracing the changes involved in overhauling a large scale website, and so level handedness is most certainly required amongst those in command.

Most importantly, don't let the pressures of these comments, nor the weight of the company's reputation on your shoulders to falter the project. Just as their is risk involved, so too is there massive potential to make your website deployment a roaring success, simply by educating yourself about the likely issues you’ll encounter and making sure that you’ve planned for and mitigated important risks.

To delve even deeper into the most common obstacles of deploying large scale enterprise websites – and how to avoid them, read Magnolia's brilliantly explanatory white paper, The Top Ten Pitfalls Of Large Scale Website Deployments.