Once the data warehouse has been designed, built and tested it needs to be deployed so it is available to the user community. This process is also known as ‘roll-out’. This can vary in size from a single-server local deployment (deployed across one country or one location) to a global distributed network involving several time zones and translating data into many different languages.

It is never enough to simply deploy a solution then ‘leave’. Ongoing maintenance and future enhancements must be managed; a programme of user training is often required. Apart from the logistics of the deployment itself. Timing of a deployment is critical. Allow too much time and you risk missing your deadlines, too little and you run in resourcing problems. As with most IT work, never underestimate the amount of work involved and therefore the amount of time required.

The data warehouse might need to be customised for deployment to a particular country or location, where they might use the general design but have their own data needs. It is not uncommon for different parts of the same organisation to use different computer systems, particularly where mergers and acquisitions are involved, so the data warehouse must be modified to allow for this as part of the deployment.

Roll-out to production (‘going live’). This takes place after user acceptance testing (UAT) and includes: moving the data warehouse to the live servers, loading all the live data – not just some of it for testing purposes, optimising the databases and implementing security. All of this must involve minimum disruption to the system users. Needless to say, you need to be very confident everything is in place and working before going live – or you might find you have to do it all over again!

Scheduling jobs. In a production environment jobs such as data warehouse loading must be automated in scripts and scheduled to run automatically. A suitable time slot must be found that does not conflict with other tasks happening on the same servers. Procedures must be in place to deal with unexpected events and failures.

Regression testing. This type of testing is part of the deployment process and looks for errors that were fixed at one point but have somehow been introduced by the change in environment.