In December 2025, we made a bold decision: we were going to completely rebuild our Salesforce org. No partial refactoring, no more iterations on the existing architecture, a brand new foundation, built from the data model up.
The org had been with the company for ten years since its early days. In that time, Enehano and the way we work had changed significantly. The data model and architecture needed to reflect that. We wanted a platform that would scale with us for the next ten years.
The decision came quickly. The execution was more complicated.
In this article, you'll find out:
- why we decided to rebuild the old Salesforce org rather than refactor it
- what a three-day hackathon with twenty people and five parallel streams looked like
- what we managed to launch over the weekend and where we hit walls
- how the org’s technical balance sheet changed (Apex classes, flows, components, permission sets)
- what we’d do differently on a second attempt
Tereza Janková, Delivery Manager & Michal Mach, Senior Solution Architect | TechBeer Spring ’26
A Hackathon Instead of a Project
For the actual execution, we chose a three-day hackathon, a format that works well for us when accelerating critical phases with clients. We set the dates as Friday 2nd to Sunday 4th January, deliberately just three days and out of season.
Around twenty people were on-site: ten consultants and developers, eleven business owners. The CEO, CFO, business unit leads, and representatives from marketing, finance, and the People Hub. Nobody was waiting for approvals. Nobody had to escalate. Decisions were made on the spot.
We worked in two-to-three-hour sprints with fifteen-minute stand-ups, highly compressed Scrum. It worked.
Five streams ran in parallel: Sales and marketing (including the migration from Pardot to Marketing Cloud Next), People Hub, timesheets, cost model, and finance. In total, the hackathon burned through roughly eighty man-days.
What Worked and What Didn't
Over three days, we launched Sales and the People Hub, including data migration. Anyone who’s done data migration knows that building an entire data model, processes, and migration in a single weekend is not a standard feat.
We also ran a proof of concept during the hackathon for integrations with Jira and Fakturoid, added a connection to the Czech National Bank, and got MergeConnector up and running.
Marketing Cloud was the weak spot. The decision to switch to Marketing Cloud Next had only been made in mid-December, and the migration included deploying Data Cloud. It only started working correctly on the third attempt.
The second area that required fine-tuning was integration architecture. A hackathon is about rapid prototyping. Production-grade robustness gets refined during go-live. When we went into real operation in Jira, we identified spots that needed further work. It took a week to sort out.
The Technical Balance Sheet
The number of Apex classes dropped by half. However, the size of the remaining classes stayed the same or grew. Two reasons: new integration services, and the rewrite of people allocation from flow to Apex. For this particular area, Apex proved to be a more reliable runtime than flow.
We significantly reduced the number of active flows. Lightning Web Components went from twenty-seven down to ten. Power components that didn’t make sense in the new architecture were replaced with standard solutions.
Show Toast Message Action
Custom fields on key objects number approximately 1,200 items. We used to have 126 permission sets. We switched to a group-based access model organized by domain and now maintain around twenty.
The most satisfying outcome: we managed to move reporting out of Tableau and directly into the CRM. Finance now builds their own dashboards, and the data has a better structure than before.
What We'd Do Differently Next Time
If we did it again, we’d arrive at the hackathon with solution designs complete at the technical level, not just the business level. Many architectural decisions were made on the fly in real time. Some of those were revisited after go-live.
People allocation alone took around ten man-days of solution design during the hackathon. We never got to implementation during the hackathon itself, and we were catching up on it throughout the entire Q1.
One key success factor remains unchanged: company leadership stood firmly behind the project from the start and was its driving force. Because they participated in the hackathon directly, decisions were made without delay. Waiting for approvals would have killed the pace entirely.
