dltHub migration services give Navit production-grade data and Chat-BI, without hiring

About Navit

Navit is a Berlin-based corporate mobility platform founded in 2021. The company helps HR and fleet managers at enterprise and mid-sized German employers manage employee mobility benefits in one place, including the Deutschlandticket, mobility budgets, bike leasing, home EV charging, and fleet management. Navit automates the tax compliance and payroll integration that normally consumes hours of HR time each month. Customers include Deloitte, Lufthansa, Babbel, GetYourGuide, apoBank, Porsche Consulting, and DACHSER.

Like most B2B SaaS companies, Navit runs go-to-market on HubSpot and operations on a SQL backend, which is one of the most common data-stack shapes in mid-market software today.

"We weren't looking for a custom rebuild, and we didn't want to staff up a data team to run something we couldn't sustain at our size. dltHub's toolkit took what we already had, structured the parts that needed cleaning up, and gave us back a stack we can confidently run, with Chat-BI on top that actually understands our business." Martin Miodownik, CTO & Co-Founder, Navit

A first-generation stack that reached its natural ceiling

Two years ago, Navit built a first-generation data pipeline to unblock reporting and analytics. The team used dlt for ingestion, Airflow for orchestration, and a hand-maintained transformation layer on top. It did its job. The business got answers, dashboards shipped, and the data team stayed lean.

By year two, the system was ready for its next step. Pipeline reliability had settled in the 80 to 90 percent range. The semantic model, meaning the working definitions of an "account," when a "deal" is really a "deal," and how HubSpot activities map onto product events, lived partly in code and partly in one contributor's domain knowledge. New tables and fields had been added over time, and shipping a new metric meant reading through end-to-end SQL on each occasion. None of this was broken, exactly, but it was no longer the right shape for where Navit was heading.

The standard playbook here would be to hire a senior data engineer to redesign the pipelines, a data modeler to author a proper semantic layer, or an analytics engineer to maintain it. That's three salaries, several months of recruiting, and a long-term bet that the right people will stay long enough to pay back the investment.

Navit, however, chose a different path. The team ran the dltHub AI Workbench ontology-driven transformations toolkit against the existing pipeline.

What the toolkit actually did

The toolkit is built around a clear idea that the way off a first-generation stack should be a product, not a custom rebuild. Applied to an existing pipeline, it handles work that would otherwise take weeks of whiteboard sessions and senior-engineer time.

For Navit, that meant:

• Reverse-engineering the existing SQL into a draft ontology. The original transformation layer was treated as a specification rather than something to throw out. The toolkit lifted it into a semantic model and flagged the places where the original interpretation didn't quite match how the business runs today.
• Consolidating into a small set of clean concepts. Stray tables and ad-hoc fields were either promoted into proper attributes of canonical concepts (Person, Account, Interaction, Deal, Product Event) or retired. The reporting surface shrank, and each remaining concept now has one clear definition.
• Generating a Canonical Data Model and a clean transformation layer from the ontology. Transformations became declarative, driven by the semantic model rather than maintained by hand.
• Moving execution onto dltHub. The previous Airflow setup was retired, along with its operational overhead.
• Adding Chat-BI on the same semantic model that powers dashboards and exports. One definition per concept, used consistently everywhere.

The toolkit handled the structural work, so there was no separate modeling project and no multi-month rebuild on top of it. Navit's team stayed involved to make sure the model lined up with how the business actually runs.

Why Navit didn't need to hire

Four things made the "no new data team" outcome work.

Knowledge moved from people to the company

In a typical first-generation stack, the semantic model partly lives in one person's head. With the ontology in place, that knowledge sits in a versioned artifact Navit controls. Anyone who needs to understand how the business is modeled can inspect it, and it doesn't leave the company when someone changes roles.

The LLM acts like an analyst, not a SQL guesser

Because the ontology is a real semantic model, with entities, relationships, metrics, and business rules, Chat-BI doesn't have to guess at SQL against raw tables. It reasons about the domain with the same context a good analyst would bring. Navit gets analyst-grade output without putting a full-time analyst in the loop for every question.

A generalist can maintain the stack

The harder design decisions are encoded in the model. Day-to-day maintenance, such as adding a field, adjusting a metric, or onboarding a new HubSpot property, doesn't require someone who can architect complex systems from scratch. It requires someone who can read the ontology and make small, well-scoped changes.

The FDE migration compressed the timeline

Forward Deployed Engineers from dltHub ran the migration alongside Navit's team, which meant the work that would normally fill a multi-month rebuild landed in weeks. The FDEs brought the toolkit, the playbook, and the pattern recognition from running this on other first-generation stacks, so Navit didn't pay for the learning curve. By the time the migration was done, the ontology, the canonical model, the new transformation layer, and Chat-BI were all in place, and the generalist who now maintains it had been onboarded in parallel.

"Navit is a textbook application of the toolkit: HubSpot plus an operational DB, a first-gen T-layer that had drifted, and a semantic model that lived in one contractor's head. The 'just hire a data team' answer doesn't work for most mid-market companies. The toolkit is the productized alternative." Matthaus Krzykowski, CEO, dltHub

dltHub powers Navit's next phase with the team it already has

Navit now operates with production-grade data capability on a cost structure that doesn't require three new hires to sustain. The ontology stores institutional knowledge. The LLM provides analytical context. The toolkit generates the infrastructure. A generalist maintainer keeps it running.

The "year two" situation Navit was in is fairly common for mid-market data stacks built in the last two years. Any team with HubSpot, an operational database, and a first-generation transformation layer sits close enough to Navit's shape that the same approach is worth a serious look.

Is your stack shaped like Navit's? HubSpot plus an operational DB, an Airflow setup someone built in a hurry, SLAs in the 80s, and a job description for a senior data engineer sitting open on your desk. You are exactly the team the toolkit is built for.