When Backe, one of Norway’s largest general contractors, signed a group-wide agreement with Rucoria, implementing a new platform was only part of the job. Years of project history also had to come along.
Across twelve regions, more than 100 active projects and large volumes of historical data had to be extracted from legacy systems, mapped into a new structure and validated — while Backe continued its normal operations.
And “historical data” meant much more than old project files. It included warranty cases and their case histories, communication between Backe and homebuyers, photos and documentation, drawings and O&M documentation, inspection records and signed handover protocols.
This was information Backe’s teams could still need years after a project was completed.
The migration programme took several months and was completed according to plan. But the most interesting part was what happened along the way: as the teams learned, the migrations became faster and more repeatable. By the final region, the data migration itself was completed in a single day.
Why bring the history?
There is a simpler way to implement a new platform: draw a line in the sand.
New projects and cases go into the new system. Everything historical stays where it is.
That makes the initial migration easier, but it can make everyday work harder for years afterwards.
A warranty case submitted today may concern a home handed over several years ago. The person handling it may need to see earlier cases, communication with the homebuyer, photographs from an inspection, drawings, previous decisions or signed handover documentation.
If that history remains in a legacy system, employees have to move between old and new platforms depending on when a project or case originated.
Backe wanted a different outcome: one place to work with both the past and the present.
Bringing the historical data into Rucoria also makes that history part of the same data foundation as new projects and cases. Instead of simply storing old information for reference, Backe can use historical and current data together to identify patterns, compare projects and regions, and build a more complete picture over time.
And project history can matter long after handover. If questions or disputes arise years later, being able to retrieve what was reported, communicated, documented, resolved and signed can be critical.
The goal wasn’t simply to preserve Backe’s historical data. It was to keep the information that mattered accessible, connected and useful.
Twelve regions, one migration playbook
Backe operates across Norway with local companies in twelve regions. Over the years, those companies have accumulated substantial amounts of project data across legacy systems.
But the systems weren’t the only variable. Backe used them differently, reflecting their projects, local processes and ways of working.
That meant migration couldn’t simply be a matter of running one generic import script twelve times. The data had to be understood, extracted, mapped to the right structure in Rucoria and validated for each region.
The scale varied too. Individual companies could have roughly 5,000 to more than 15,000 cases to bring across. And a single project could contain a substantial amount of information on its own. One project, for example, included more than 12,000 files representing over 16 GB of data.
Backe’s decision to make that move followed years of evaluating different solutions. As Mårten Skällenäs, former Director at Backe Entreprenør AS, puts it:
“We have tested various solutions over the years and find that Rucoria has a unique platform that is both highly flexible and meets existing and future needs. We are also impressed by how the team works and their ambitions, which is why it is natural for us to collaborate closely with Rucoria.”
Rather than attempt one group-wide cutover, Backe and Rucoria divided the programme region by region: twelve migrations run in sequence, following the same overall playbook and refining it each time.
Start carefully. Learn. Then accelerate.
The first migrations took the longest.
The teams spent several weeks planning, developing migration tooling, mapping data structures, testing transfers and validating the results. That work established the foundation for everything that followed.
Each completed region produced new knowledge. The tooling improved. The teams became better at identifying differences in how data had been structured and used. Validation became more efficient, and issues that had required investigation the first time could increasingly be anticipated.
As a result, the programme accelerated.
Towards the end, multiple regions could be handled within a single week. For the final region, the data migration itself was completed in one day.
That acceleration wasn’t the result of cutting corners. It came from having encountered and solved many of the difficult problems earlier in the programme.
By then, migration had become a repeatable process rather than a new project every time.
Moving the right data to the right place
Rucoria’s engineers built dedicated migration tooling to extract structured data and files from the legacy systems and move them into Rucoria.
But extraction was only part of the job.
Because Backe had used their existing systems differently, the migration setup had to be adjusted and validated for each one. The team needed to make sure the right data was extracted, that old structures were mapped to the correct places in Rucoria, and that what arrived matched what was expected.
Large migration batches could be processed in parallel to reduce transfer time. Throughout the process, data and files were checked and tested, with final count checks used to verify the migration.
Nothing was considered complete simply because an import had finished.
And not everything went automatically. A small share of files failed validation on the first pass — for example because of file formats or oversized attachments — and needed manual handling rather than a clean, scripted transfer. In one region, parts of the source data were not structured cleanly enough to map automatically, so housing type classifications had to be corrected manually afterwards.
There were also deliberate decisions about what not to migrate. Some older case history stored in a separate CRM system was kept outside the migration scope after weighing the effort required against how likely that information was to be needed in day-to-day work.
That distinction matters: a successful migration is not necessarily about moving every piece of historical data. It is about understanding what needs to move, mapping it correctly and verifying that the result can be trusted.
A migration of this scale still needs human judgement and quality assurance, not just a script reporting success.
Each company also required a controlled cutover. At an agreed point, new customer submissions to the legacy system were temporarily closed, the final data was extracted, migrated and validated, and the company was then opened for new cases in Rucoria.
Across the full programme, Backe maintained normal operations while the companies moved onto the new platform.
As Martin Borg, Quality Manager at Backe Entreprenør AS, puts it:
“After choosing Rucoria, we wanted all our projects and data in one place. Migrating more than 100 active projects and thousands of homes while maintaining normal operations required careful planning and close collaboration. Thanks to skilled teams in both organisations and a strong working relationship, the transition has been remarkably smooth.”
Backe’s programme also ran alongside other legacy-system migrations handled by Rucoria’s team during the same year. Experience across these projects helped strengthen Rucoria’s migration tooling and approach further.
Technology mattered. So did the people.
A small core team drove the programme across the group. Oskar Björk and Victor Minge on Backe’s side kept the implementation process moving, while Martin kept the wider programme on track. A dedicated data specialist handled the technical extraction from the legacy environment, working closely with Rucoria’s technology and customer success teams.
Clear ownership and firm but realistic deadlines kept the programme moving. Just as importantly, people from the individual companies were involved early.
They knew the projects, understood how their region had actually used the legacy systems and could help distinguish between technical anomalies and information that genuinely reflected local ways of working.
The teams also accepted that a migration of this scale could not be designed perfectly on paper before it started. Short, frequent status meetings were used to clear blockers and make decisions, while the overall approach remained iterative: migrate, validate, learn and improve.
Migration and adoption happened together
Backe and Rucoria did not treat data migration and implementation as two separate projects.
When a company moved to Rucoria, its historical projects came with it. At the same time, the people who would actually use the platform received training and started working with it in the context of their own projects and responsibilities.
That timing matters.
Training users centrally and then asking them to apply what they learned months later creates an unnecessary gap between learning and doing. Backe instead combined local onboarding with the point at which each region was actually moving onto the platform.
Users could learn Rucoria using familiar projects, familiar cases and real work.
Migration, implementation and adoption happened together.
What Backe has today
Backe now works on the same platform, with shared processes and templates across residential and commercial projects.
For the people working with customers and projects day to day, historical and new information is available in the same environment. A new warranty case can be handled with the relevant project history already accessible, rather than requiring users to search across old and new systems.
What one company learns or builds can also be reused elsewhere rather than recreated locally. And with historical and current structured data on one platform, Backe has a stronger foundation for identifying patterns, comparing projects and regions, and learning across the group.
The immediate benefit is simpler day-to-day work.
The longer-term benefit is a shared data foundation.
Seven lessons from the migration
Every legacy environment is different, but several lessons from the Backe programme apply well beyond this particular migration.
1. Give the migration real ownership. Dedicated resources are needed centrally and locally, with clear roles, responsibilities and authority to make decisions.
2. Make it a priority. Migration can’t be something everyone agrees is important but nobody has time allocated to complete. Firm, realistic deadlines create momentum.
3. Bring local users in early. The people closest to the projects often understand the data better than anyone else. Their knowledge matters when translating historical structures into a new platform.
4. Decide what is worth migrating. More data is not automatically better. Define what people will actually need, what has long-term value and where the effort of migration is justified.
5. Don’t wait for perfection. Large migrations reveal things that cannot be predicted from a planning document. Move forward, validate, learn and improve.
6. Combine migration with implementation. Bringing the historical data across and introducing the new way of working at the same time makes the transition more useful from day one.
7. Train people when they need the knowledge. Local, project-specific onboarding close to go-live is more useful than generic training long before users start working in the system.
Perhaps the biggest lesson is that large migrations don’t become simple. They become manageable when the right people, tooling and process are in place.
A partnership that goes both ways
The programme also changed Rucoria’s own migration capabilities. Every region created another opportunity to improve the tooling, validation methods and playbook — knowledge that can now be applied to future migrations.
Lars-Thomas Stene, CCO at Rucoria:
“Backe asked hard questions and held us to a high bar throughout — that’s exactly the kind of partner that makes us better. Every region we migrated together taught us something we’ve since built into how we do this for every customer. We didn’t just move Backe’s data — we grew alongside them.”
Planning a similar move?
Historical project data shouldn’t be the reason an organisation stays on a legacy platform.
The Backe programme showed what a structured approach can achieve: more than 100 active projects moved across twelve companies, years of project history brought into the same environment as new work, and a migration process that became faster and more repeatable with every company.
If you’re considering a move from an existing construction platform and want to understand what migrating your projects and historical data would actually involve, get in touch with the Rucoria team.
