KLP Eiendom has fully retired Sesam and now runs its operational data hub on RisingWave. The Norwegian property company uses streaming SQL to bring customer, property, and operational information together and deliver prepared results to business applications and reporting.
The migration addresses a challenge facing other Sesam customers: replacing an integration platform while preserving the business relationships and rules built around it. For KLP Eiendom, the result is a working replacement with a SQL foundation that can support new integrations and analytical uses.
A new foundation for property operations
KLP Eiendom is the real estate subsidiary of Norway’s KLP group. Property development, letting, and management depend on information spread across finance, CRM, building management, and other operational systems. A customer application needs a coherent view of a tenant and their contracts; property teams and reporting tools need consistent business information.
Sesam provided the integration hub connecting those systems. The platform combines and transforms data from different applications and synchronizes the results with downstream consumers. KLP Eiendom used it to bring together information that no single source system held on its own.
With Sesam Hub being phased out, KLP Eiendom needed to replace that central role. The challenge was to carry forward the business logic: reconcile overlapping records, preserve shared definitions, and provide information in the form each application needed.
Why RisingWave fit the workload
KLP Eiendom’s integration requirements align with three capabilities in RisingWave:
SQL for business transformations. Customer and property models involve combining related records, enriching information, and preparing summaries. SQL expresses these relationships in models that engineers can inspect and revise.
Several ways to receive and deliver changes. Native SQL writes, database CDC, and webhook ingestion accommodate different input paths. Prepared results can be delivered to application databases, event-based integrations, and analytics destinations.
Continuously maintained, queryable results. Materialized views keep the output of joins and aggregations current as inputs change, making the same business information available for downstream delivery and queries.
Together, these capabilities let RisingWave take on the transformation and distribution work at the center of the hub. Source applications retain their business roles, while RisingWave maintains the shared information used across them.
From source records to useful business views
Business data enters through SQL writes, CDC, and webhooks, combines in materialized views, and reaches operational applications and reporting.
Business data enters through SQL writes, CDC, and webhooks, combines in materialized views, and reaches operational applications and reporting.
External integration services read upstream systems and write records through SQL. Database CDC and webhook ingestion provide additional native paths into RisingWave. Within the database, materialized views store query results and update them incrementally as incoming data changes.
The transformations prepare information for business use:
| Business information | Transformation | Useful result |
|---|---|---|
| Customer information | Combine complementary records across systems | A shared customer profile for applications |
| Property information | Bring related records together and calculate summaries | Consistent property views for operations and reporting |
| Commercial and operational records | Standardize and prepare information for consumers | Data ready for customer service, workflows, and reporting |
Customer information provides a concrete example. Finance and CRM contribute different parts of a customer record. RisingWave combines those inputs into a shared model, then prepares the representations needed by downstream applications and reporting. When an input changes, the shared result is maintained rather than assembled independently for every consumer.
Results leave the hub through database sinks and event-based integrations, with BigQuery serving analytical use cases. Applications can also access shared information through an API.
What KLP Eiendom has achieved
The replacement is complete: KLP Eiendom has fully stopped using Sesam, and RisingWave now serves as the core of its operational data hub.
The deployed architecture brings customer and property transformations into shared SQL models and supplies their results to business consumers. This gives KLP Eiendom a common transformation layer for operational integrations and reporting. The customer model illustrates that outcome: information from different source systems is reconciled centrally and reused across downstream uses.
The completion of the replacement establishes that RisingWave can support this integration workload in practice. Its SQL and streaming capabilities also provide a foundation for evolving the hub as business requirements change.
“Replacing Sesam meant carrying forward the business integrations we rely on. With RisingWave, we can express that logic in SQL and use shared customer and property models across our applications and reporting.”
Truong Le, Head Engineer, KLP Eiendom
Beyond replacement: room to evolve
Flexible business logic in a familiar language
Sesam defines transformations through its Data Transformation Language. RisingWave brings that work into SQL: a model can be extended with another field, join, or calculation, and its result reused by another consumer. PostgreSQL-compatible interfaces and dbt integration connect that approach to familiar database tools and SQL development workflows.
For an evolving integration hub, this creates a practical way to change business definitions and add outputs without starting each integration from scratch.
Business views maintained as data changes
RisingWave continuously maintains joined and aggregated results as new data arrives. Applications can read a prepared customer profile or property summary without triggering a separate full recomputation of that view.
This is the real-time foundation the architecture provides. Overall freshness still depends on how quickly upstream data reaches RisingWave, including the cadence of any polling services.
Integration and analysis from shared definitions
A business model prepared for application delivery can also be queried or used as the basis for another analytical model. A new report or service can build on existing customer and property definitions, with additional transformations where needed.
This extends the value of the replacement: the hub becomes a place to develop reusable business information as well as distribute it.
A practical path for other Sesam users
KLP Eiendom’s experience offers a concrete example of moving from Sesam to a streaming SQL data hub. The essential work is to preserve the business information applications depend on, then use shared models to support future needs.
For a team evaluating its own replacement, one representative customer, property, or other business model is a useful starting point. Its inputs, transformations, and required outputs provide a focused way to assess fit.
For teams exploring a similar migration, KLP Eiendom has shared its Sesam-to-RisingWave migration repository. It includes SQL and dbt models, ingestion patterns, and migration validation tools—a practical reference for understanding how existing Sesam integrations can be mapped to streaming SQL.
Planning a Sesam replacement? Complete the RisingWave questionnaire to share your workload and evaluation requirements, and we will get in touch with you shortly.
