In the previous post we explored how to organize the process of developing your website.
The most widespread mistake of the roll-out phase is not thinking beyond website functionality. There are common deployment pitfalls that can eat a lot time, energy, and money, unless you foresee and prevent them in advance.
The first thing you need to decide is where your project will physically reside.
There are several options:
- In-house infrastructure: you will have full control of the system behind the firewall, but also the headache and responsibility of maintenance tasks. Do you have enough resources to ensure website availability?
- Partner infrastructure: you will keep commercial relationship with the subcontractor, which is also wise if you plan to grow the system further. Are you ready to pay recurring hosting and technical support fees?
- External data center: you will get first-class infrastructure at reasonable rates, but not the passion to maintain the system, nor support flexibility or response time. Do you know who to call when the website breaks down at 3am?
Allow at least a couple of days, or even a week, for migration from development to live servers, soft launch, final testing, and going public. This is especially important if your CMS is resource-intensive.
Before migration, system administrator should inspect the differences at all levels: hardware setup, environment configuration, and software settings that might affect the normal operation. All the QA procedures described in part 5 should be conducted at project’s final location including evaluation and acceptance of the features.
If you are extending an existing website, consider the effort needed for data and code synchronization, it really is not that simple.
Experience shows that user acceptance heavily depend upon your company culture. If you are a larger organization with policies and procedures, it might take a while before everybody get used to the new rules.
Do not expect editors to to be fluent with the system right away, even if it has easy-to-use interface accompanied by comprehensive user manuals. Instead, the learning curve should start with content administration training, often provided by subcontractors.
Support software adoption by internal company-wide message on the role of the new website in corporate communications. Make people excited about the change, and turn transition into a fun experience.
If you have a clear vision of how content is generated, approved, and published in your company, the system might be capable of modelling existing roles with configurable access permissions and editorial workflows.
Automated authoring process and flexible information structure are vital for effective content management. Integration with centralized document repository could also be possible.
I know we spoke about it in part 4, but it’s worth repeating: creating content is a time-consuming task. In fact, it is recommended to start writing at the very beginning of the project if you want to finish it in time for launch.
Don’t fill the text with “keywords” for SEO, it is an outdated practice. Instead, think about your target audience and what they would like to know, provide useful information only to stimulate social sharing. Keep the text short and well formatted, support your presentation with relevant images to express emotion, or diagrams to clarify the subject matter.
A launched website is like a new car: it shines the first time your friends see it, but then you occasionally need to take it to a garage, at least to change the oil. A comparable cost of development should have hinted it in the first place.
The inconvenient truth is that no system is perfect. Smooth operation can be influenced by:
- Hardware and software upgrades
- Large arrays of data or high traffic
- Insufficient disk space or other settings
- Unexpected vulnerabilities and human factor
- Bugs or minor inconsistencies
If you want to protect your investment and make sure the system is stable, accessible, available, fast and secure at all times, you need to arrange commercial technical support and ongoing maintenance services.
Your subcontractors should be able to provide product responsibility and other guarantees in the form of a service level agreement that fits your needs. Ask for:
- Bug fix guarantee
- Fixed response time to any issue
- Updates to the newer versions of CMS
- Automatic health monitoring
- Dedicated manager contact
- Regular checks and audits
The overall security of a content management project depends on many factors: physical infrastructure, the operating system, underlying software, the CMS product, application access control, the data transmission mechanism and human issues. Make sure you discuss with your subcontractors and/or CTO how each layer is protected.
In extreme cases, you might want to achieve high availability, consistent performance, and fault tolerance. Professional CMS provide built-in support for such architectures, for example cluster setup, to ensure bulletproof system reliability and resulting business continuity. Talk to your subcontractors and/or CTO to deploy it properly, it is a project on its own.
If you have done everything correctly, you probably love your brand new website and plan to extend it. For this purpose you need to continue an ongoing relationship with your original subcontractors, or build your own independent team. They will provide you with training courses, custom workshops, project consulting, and custom development in the future.
Thank you for your time reading our blog series. We would love to hear your feedback, please leave a comment or subscribe to our social channels listed on the right.
Part 1: Start a web project
Part 2: Select your CMS
Part 3: Select subcontractors
Part 4: Define requirements
Part 5: Organize development process
This work is licensed under a Attribution-ShareAlike 3.0 Unported License