Data warehouse consulting in Iceland usually follows the same shape: map the sources, agree the definitions, build the pipelines, check the data, then hand over something your team can run. The technology matters less than the order you do things in. This post walks through a typical project for an Icelandic company, week by week, with two of our own projects as examples.
A data warehouse is one database where data from all your systems is stored the same way. Accounting, CRM, bookings, payroll and the spreadsheets people keep on the side all land there, cleaned and joined. Reports then read from one place instead of five.
The point is not storage. It is agreement. When finance, sales and management read from the same tables with the same rules, the monthly meeting stops being about whose number is right.
Weeks 1 to 2: what do we have, and what does it mean?
The first weeks are discovery. Nothing gets built yet. We:
- List every source system, who owns it, and how data can be taken out: API, database access, or file exports.
- Audit the legacy systems. Old systems often hold years of history in formats nobody has opened in a while.
- Collect the questions people want answered, and the reports they rebuild by hand each month.
- Write down the definitions that cause arguments. Is revenue counted on the invoice date or the payment date? Is a cancelled order with a fee a sale?
The output is a short document: sources, owners, definitions, and the first three reports to rebuild. It is the most useful thing in the project, and the cheapest to change.
Weeks 3 to 6: how does the data get in?
Next come the pipelines. This is ETL (extract, transform, load) or ELT, where data is loaded first and transformed inside the warehouse. Either works. The rules matter more than the acronym.
- Extract from each source on a schedule.
- Transform into one shape: one currency rule, one date rule, one code for each product or customer.
- Load incrementally. After the first full load, bring in only what changed. Loads stay fast and reporting stays close to real time.
We start with the one or two sources that feed the most important report. Usable reporting from the first month is a better goal than every source at once.
How do you know the numbers are right?
Every pipeline needs checks that run on each load, not once at the end. The useful ones are simple:
- Row counts against the source.
- Totals reconciled against the accounting system for a closed month.
- Alerts for missing days, duplicate records and values outside a sensible range.
- Tests that Icelandic characters survive each step, so names with þ, ð and æ still match.
When a check fails, the warehouse should say so before a manager finds it in a dashboard.
Where should the data live, and who can see it?
Governance is part of the build, not a later phase. Two questions come up on every Icelandic project.
Hosting. Iceland applies the GDPR through Act no. 90/2018, and the GDPR requires extra safeguards when personal data leaves the European Economic Area. Keeping the warehouse and its backups in the EEA is usually the simplest answer.
Access. Decide who sees what, by role, from the start. Salary data, personal records and grant applicants should not be visible to everyone who can open a sales report.
What does it look like in practice?
For KMÍ, an Icelandic government body that manages grants and reimbursements, working with Móholt, the project ran in four phases: discovery and a legacy systems audit, warehouse implementation and migration, Qlik Sense app design and user testing, then training and support. Access controls and data quality monitoring were built in. Report generation went from days to minutes.
For TourDesk, data from hotels, vendors, suppliers and car rentals was joined into one governed data foundation. Incremental loads keep reporting near real time, and governance covers data quality and GDPR. It runs as an ongoing project with continuous improvement.
How long does it take, and what do you get at the end?
A first phase with one or two sources and a few trusted reports typically takes a few weeks. A larger build with many sources and a migration runs over several months. Each new source after the first is a smaller job, because the model and the rules already exist.
At handover you should have:
- The pipelines, running on a schedule, with alerts.
- A written list of definitions and where each one is applied.
- Documentation your team or another supplier can follow.
- Training for the people who will maintain it.
If you want one place for your company's numbers, our analytics work shows how we build it, our approach explains how we run projects, and you can tell us where you are today.