DGD Consulting

Changes to a site come in many shapes and sizes:-

• Minor corrections – usually a small coding error on a page or deficiency in content. Often requires just a quick edit to a page and its redeployment.
• Small changes –a minor change to a small corner of the site. The change is unlikely to involve significant design work and is usually implemented to address design shortfalls or functional errors.
• Functional Changes – this may be a redesign of one function on the site – with a limited knock on effect to other pages on the site in terms of links and linking content.
• Upgrades – the site may require a number of functional changes across the site, a look and feel revamp or a complete rewrite.

This section concerns itself with the last two change types, where implementing the changes may cause some disruption to the website. When making changes be clear to understand and document:-

• the perceived problem(s).
• the possible solution(s).
• the cost of those solutions (not just in time and money but also in down time and potentially withdrawn functionality).
• the benefits of the change – these benefits should be quantifiable, as they will form the basis of targets by which success can be gauged.

If the website is being upgraded, then other changes not implemented in the last release, or added to the “wish list” since that release, could be considered for inclusion. It’s also worth canvassing colleagues, customers and potential customers for additional ideas. However, do NOT include too much change if there is a risk of compromising the objectives of the primary changes.

If the planned changes are a significant amount of work then this should be considered as a major project. The proposals should be taken forward and the website planning process followed as it was for the initial design.

Upgrading an existing site has one additional complication.

ITS LIVE!

The planning must incorporate plans to avoid major disruption to any services provided by the site. Plans must be in place to cover some or all of the following:-

• How to migrate data from the old system that is needed by the new system (without data loss).
• Minimise the impact for end users.
• Maintain any transactions that are in progress at the time of cut-over.
• Rehearse the release, test the migrated data and rehearse a roll-back should things go horribly wrong.

Each migration needs to be looked at individually, but generally the options are:-

• For a site or part of a site that is only used for viewing data, the switchover could be as simple as removing the current pages and replacing with the new pages, and moving from the old database format to the new.
• Sites that process customer data need to be more careful to maintain any customer work in progress:-
  • Maintain two systems in parallel – whilst the work in progress on one system winds down and forcing new work to commence on the new system.
  • Have downtime whilst the final data transfer takes place from one system to another and the new web pages are deployed.

In all cases there needs to be a strategy for going back to the old site should there be unexpected problems when going live.