Skip navigation.

Databases > Implementing A Database

Implementing a database – practical and strategic issues

By Dr Simon Davey

Database implementation is straightforward but easy to get wrong. This article provides a ‘how to’ guide and checklist to get it right every time.

The implementation phase of a database project requires careful management and there are key practical and strategic issues to consider.

By this stage, you’ve already spent time planning, identified specific requirements, selected a supplier, bought a package, made customisations and identified any necessary improvements to your ICT infrastructure. It’s time to implement your system.

The key things to remember for a successful implementation are:

  1. Take it slowly – rushing leads to error
  2. Pay attention to detail
  3. Clean up your data before you add it
  4. People are your biggest issue (and asset)
  5. Evaluate what you do

Installing the system

Before you install the system, make sure your ICT system and infrastructure (server, network, PCs etc.) is up to scratch. Will you be able to run all your software at once (databases can be hungry for computer resources)? Nearly is not good enough. Once you’re satisfied. It’s time to install it.

Key point: Good databases perform badly on poor/old servers/PCs.

The role of the database manager/administrator

You must have someone in overall day-to-day charge of the database (often called the Database Manager or Database Administrator). They are the first point of call for problems, liaise with the suppliers and keep an eye on issues and developments. They should also link in to senior management and recommend decisions on changes and future expenditure. Appoint them before installation.

Change management

A shared database can be a culture shock. Demonstrate what difference the database will make to individuals as well as the organisation.

Listen to needs and concerns. You don’t want people working around the system and not using it. Fear of change is a big issue. Set practical, manageable expectations.

The first few weeks will be time consuming and problematic. Major benefits take a little while. The biggest challenge is when a system offers a big improvement to the organisation but may have a negative and demanding impact on specific users.

Key point: People are the key to an effective database.

Data clean up

However good your database is, you need to put data in and get information out. It takes time and effort and you’ll probably need a good spring clean of what you have. (If you’ve never had a database before and don’t intend adding old data you can skip this bit).

List every source of data you have. Your colleagues probably have an Excel spreadsheet each, perhaps a few Access databases, an old ‘main’ database and contacts in Outlook. Compile your list, collate the data and clean it up.

Imagine moving home – you don’t simply bundle rubbish into boxes and pile it out again. Sort out, clean up and throw away as you go along. A new database won’t sort out bad data or tidy up a poor filing system.

Key point: Only ever add clean data to a new system.

Data migration

  1. Decide what data structure you want (you’ll probably have done this when you bought the system)
  2. Check your data (you can do this manually or have suppliers write scripts [small computer programs that match data and ask you to check problems])
  3. Throw away duplicates (e.g. someone with the same name and three different phone numbers they no longer have) and make sure the data is clean.

One simple tip for migrating data is to convert everything into an Excel spreadsheet and check it line by line. Always make sure you have a back up copy of data.

You might decide to do data migration manually. For small amounts of data, it’s easier to type in information you know is accurate and ignore the rest.

Testing times

Off the shelf software should do what it says on the box. If you buy a more complex package (or something built from scratch), you’ll need to rigorously test the system to check it works.

In either case, you’ll need to ensure the system does what you expect the way you expect it before you use it in a ‘live’ environment.

If you are having a system developed from scratch or a lot of tailoring to an existing system, you’ll need to employ formal testing. Formal testing has two stages:

  1. Product testing – preliminary testing to check the system does what it’s supposed to
  2. User testing – this usually happens after some basic ‘overview’ training and gives users the opportunity to break the system (better now than later).

It’s important to ensure the system works the way you want it to. Off the shelf or not, you need to let key users play with the system and find idiosyncrasies before they depend on it day to day. It’s too late when you’re in the thick of client work to find it doesn’t do it the right way or takes twice as long as it did before.

For any system, there are two ways to test – use both:

  1. Scripted or structured testing – you follow a script/process and perform a key task e.g. adding a contact, writing a report or managing an event
  2. Monkey testing – you try your best to break the system and see what weird and wonderful things it can do (that it shouldn’t)

You’ll need to write test reports and have someone to manage and oversee testing.

After testing, you may need to redevelop parts of the system or change your expectations or processes.

Key point: The time and effort you invest now will pay off quickly. Better to find the problems before you use it for ‘mission critical’ work.


Most people in your organisation probably get by with simple software. Don’t assume they can do the same with your database. You need everyone to use it the same way (more or less).

Investment in training is key to a successful system because:

  1. People are happier with the system and are ‘bought in’ to its success
  2. People work more effectively with it (and don’t go back to their spreadsheets)
  3. Processes are done the ‘organisational’ way - systematically
  4. People are more efficient and better able to get on with their job

Key point: Don’t ever install a new system without training everyone who needs to use it. The users will rebel and the system will fail within months.

Setting standards

The more people who use a system, the more you need standards and agreed processes. It’s important to set these in advance and make sure everyone is signed up and agreed. A simple set of principles will make a huge difference to data quality and performance.

Databases work best when well set up and maintained and depend absolutely on quality data. You must agree how to manage data.

Key point: Agree standards and principles and make sure someone senior oversees them.

Go live

‘Go live’ is the day you let users loose on the system with real data to use for their day-to-day work. If you can, let one department get to grips with the database at a time - maybe phase the implementation over a few days or even weeks. That way if there are any last minute issues, they can be fixed before everyone finds them.

There comes a point when the whole organisation will change over to the new system. Make sure you’re ready and have a fallback position in case things go wrong.

Key point: Switch over carefully and be ready to (temporarily) go back to the old way of working if there’s a serious problem.

The need for ongoing support

Just as an ICT system should have a support contract, any serious investment in database technology will need expert help, almost always from the supplier (they built it, they know best how to fix it). This usually comes in the form of a joint licence/support contract (or online help). It can be expensive (from 10 to 20% of the system cost) but is worth it. If it breaks, you may end up with nothing.

Your first year

Your database will have a major impact, change the way you work, and requires commitment.

You should consider:

  1. A reporting (change control) process – what changes are wanted or needed and why? Are they improvements or bug fixes?
  2. Monitoring and evaluating how the system is working - what could be improved? Do people and processes need to adapt?
  3. Identifying changes (opportunities) to working practices in the organisation and unexpected issues
  4. Longer term support costs for the system to be most effective
  5. Maintaining your database champion and project steering group to support the project

Return on investment – the sums

Databases are expensive – you must measure their impact and show the difference it makes. This could be increased outputs and outcomes, better relationships, more contacts, increased efficiency or effectiveness. It will help convince trustees and funders to support you, illustrate your organisation’s impact and keep the system going for years to come.

Key point – A database is for years, not just for year end!

Happy implementation!

About the author

Dr Simon Davey
Simon Davey is Managing Associate of the and specialises in information management and databases, from business and requirements analysis to project and supplier management.


Database, ICT, Line, Network, Software, Spreadsheet, Switch

Related articles

Published: 17th August 2007

Copyright © 2007 Dr Simon Davey

User comments and discussion

If you have useful information to add to this article please Add a comment. Comments will appear after they have been moderated.

Discuss this topic in the Knowledgebase forums. This is a useful place to share knowledge, experiences, and ask questions.

Please sign in or register to be able to post a comment or discussion.