Rebuilding Tech Barcelona’s data architecture, and the trust to migrate onto it

The organisation

Tech Barcelona is one of the institutions that holds the city’s technology community together, connecting companies, startups, investors and public bodies. Marina Saurí is its Director of Strategy.

An organisation like that runs on relationships, and relationships live in data. Members, partners, events, programmes, applications. Every one of those is a record that somebody has to trust.

The situation

The tools had been chosen one at a time, each for a good reason, none of them chosen together. That is how almost every stack is built.

With the way a company moves day to day, what happens is you never stop to put things in order: where your data comes in and where it goes out.

Marina Saurí, Director of Strategy, Tech Barcelona

Her word for the result was desquadrat, out of square. Nothing collapsed. Things just did not line up, and every question took longer to answer than it should have.

The real problem

A migration is a technical job with a clear end. Move the records, point the integrations, turn off the old system.

That was never the hard part here.

If we had run the migration first, Tech Barcelona would have paid for a change of software and kept the problem. The architecture had to be decided before a single record moved, because the architecture is what the migration would carry.

So the work started one step earlier than the brief asked for: mapping where data entered, where it left, who owned it in between, and which of those paths existed on purpose.

The risk that was not technical

There is a part of this work that no scope document covers, and Marina named it before we had done anything.

It is always harder to work with people you do not see every day. With your own team you keep control: any doubt, any problem that comes up, you solve it there and then. Working with someone external always carries that fear of things being less fluid, less agile.

That fear is correct. It is the accurate default position for anyone who has hired an external team before.

It also cannot be answered with a pitch. It can only be answered with how the work actually runs, week after week, which is why the two things she eventually pointed to were not deliverables at all.

What we built

A data architecture, decided before the move. Where records enter, where they leave, which system owns which object, and what happens at each handoff. Written down as a model, not as tribal knowledge.

The migration itself. Executed against that model, so what landed in the new stack was the structure we had agreed on rather than a copy of the old mess.

Documentation of every step. Not a handover document written at the end, but the build recorded as it was built.

A daily flow of information. The remote-team problem solved in the only way it can be, by removing the wait.

How the work ran

Those last two are the reason the engagement worked, and they are what Marina talks about when asked how it went.

I like working with Oriol because he has that mental structure of leaving everything documented. When you work with an external company it is very hard to keep that follow-up, and having it all documented, the step by step, and that direct daily flow of information, that helped us a lot.

Documentation is usually sold as a deliverable. It is more useful to think of it as the thing that makes an external team safe to hire. The client can see the system being built, can check it without asking, and owns it the moment the engagement ends.

The daily flow does the same job for speed. The fear was that an outside team would be slower than an inside one. The answer is not to promise otherwise, it is to make the loop short enough that the question stops coming up.

What changed

For now, the data is in its place, which is already a lot.

That sentence is the whole result, and it is worth reading slowly. Data in its place means every downstream question gets easier: reporting, segmentation, follow-up, anything anyone wants to build next.

Marina is also clear about the part that is not finished, and she is right to be.

We have always had a certain panic about dropping tools we know and moving to new ones, and the whole team’s adaptation goes beyond the project itself. But I am convinced we did the work well, everything is where it should be, and from here it will go much better.

A migration ends. Adoption does not. The system can be correct on the day it is handed over and still take a team weeks to live in comfortably, and pretending otherwise is how projects get declared finished before they have actually landed.

What a good architecture does is make that adaptation worth doing once. The team learns a structure that will hold, instead of learning another arrangement that will need rebuilding in two years.

Why this matters

This case has no campaign metrics in it, and that is not an omission.

Nothing here was about generating demand. It was about an organisation being able to trust its own records, and about proving that an external team can do structural work without becoming a black box. Those are the two things that decide whether the next project is worth starting.

Who this is for

Organisations that have been running long enough to accumulate tools, and never had a quarter free to decide how those tools should fit together.

Where nothing is broken but nothing quite lines up. Where a migration is on the table and the real question underneath it has not been asked yet. Where the team has been burned before by an external partner who delivered something that only they understood.

If that is familiar, the problem is not the tool you are moving off. It is that nobody ever drew the map.