{"id":4111,"date":"2025-10-27T11:25:16","date_gmt":"2025-10-27T10:25:16","guid":{"rendered":"https:\/\/nubisoft.io\/blog\/?p=4111"},"modified":"2026-01-27T21:15:03","modified_gmt":"2026-01-27T20:15:03","slug":"from-object-to-document-database","status":"publish","type":"post","link":"https:\/\/nubisoft.io\/blog\/from-object-to-document-database\/","title":{"rendered":"Migrating a Legacy Object Database to a Document Architecture"},"content":{"rendered":"
\n
\n
\n
\n

Brief<\/h1>\n

The client approached us with a challenge: to modernize the database layer of a large, long-running system built on outdated technology. The goal was simple yet ambitious \u2014 to replace the legacy database engine without disrupting the application logic or affecting end users.<\/p>\n

By working together, we:<\/p>\n

    \n
  • Developed a customized migration strategy.<\/li>\n
  • Selected the most appropriate database technology.<\/li>\n
  • Created a dedicated data converter.<\/li>\n
  • Modified the system to run with the new component.<\/li>\n<\/ul>\n
    \n

    Right now, the system uses NoSQL database, which is faster and easier to maintain. It also doesn’t require any downtime or functional changes.<\/strong><\/p>\n<\/blockquote> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

    \n
    \n
    \n
    \n

    Client<\/h1>\n

    The client is a healthcare software provider offering innovative products in the DACH region.<\/span><\/p> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

    \n
    \n
    \n
    \n

    Problem<\/h1>\n

    The client asked us to help modernize the system\u2019s database layer. The existing solution ran on an thirty years old object database engine, which had become inefficient both technologically and commercially.<\/strong><\/span><\/p>\n

      \n
    • The technology did not support incremental patches, so each update required shipping a complete database to end clients.<\/span><\/li>\n
    • At this stage of the system\u2019s growth, database files were very large (\u224860 GB), making transfers slow, error prone and expensive.<\/span><\/li>\n
    • The vendor supplying the tools for creating and editing the databases raised license prices, making each new deployment commercially unprofitable.<\/span><\/li>\n<\/ul>\n
      \n

      To acquire new customers, the client had to update one of its core systems\u2019 database technology.\u00a0<\/strong><\/p>\n<\/blockquote> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

      \n
      \n
      \n
      \n

      Challenge<\/h1>\n

      Replacing the database in such a large system is a complex operation. The client wanted the system to keep doing exactly what it did \u2013 just with a more efficient and cost-effective database technology. To solve this problem, we had to answer:<\/span><\/p>\n

        \n
      • Which new database technology best fits the client\u2019s requirements and solves the current problems?<\/span><\/li>\n
      • How can we update only the database, without overhauling the system architecture?<\/span><\/li>\n
      • How do we migrate legacy databases to the new technology without losing information?<\/span><\/li>\n
      • How can we execute the update without interrupting service for end users?<\/li>\n<\/ul> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n
        \n
        \n
        \n
        \n

        Solution<\/b><\/h1>\n

        We approach problems like this without preconceived answers, focusing first on the business outcomes and then on the enabling technology choices.

        <\/span><\/p>\n

        Step 1: Selecting the database technology
        <\/b><\/h3>\n

        The first challenge we faced was selecting a new technology. When analyzing the available options, we kept in mind the reason why the customer came to us: <\/span><\/p>\n

          \n
        • The current vendor had raised prices, blocking business growth. <\/span><\/li>\n
        • The object database struggled with incremental data updates. Every change required sending the entire database file, hurting performance and raising operating costs.<\/span><\/li>\n<\/ul>\n

          Given that keeping the total solution costs down was crucial for the client, we naturally gravitated toward open-source solutions. With so many options available, we knew the new database had to be stable, high-performing, and support a flexible schema along with efficient incremental data writes.<\/span><\/p>\n

          \n

          After careful consideration, we ultimately decided to move forward with an open-source document database.<\/strong><\/p>\n<\/blockquote>\n

          Why<\/span>? Because it:<\/span><\/p>\n

            \n
          • Provides a flexible schema that maps naturally from object models.<\/li>\n
          • Enables incremental updates (to transmit only changes, not entire database files)<\/li>\n
          • Delivers strong performance on large, heterogeneous datasets.<\/li>\n
          • Offers rich querying capabilities, including filtering, aggregations, and full-text search.<\/li>\n
          • Scales reliably in distributed environments.<\/li>\n<\/ul>\n

            In short, the chosen database enables easier updates, faster iteration, lower costs, and supports further system growth.



            <\/span><\/p>\n

            Step 2: Migrating from object to document database<\/h3>\n

            After choosing the technology, we applied a <\/span>fail-fast<\/b> approach to quickly validate both the choice and the feasibility of migrating from an object database to a document store.<\/span><\/p>\n

            Together with the client, we picked a mid-sized database and built a dedicated converter that would:<\/span><\/p>\n

              \n
            • read data from the legacy object database,<\/span><\/li>\n
            • Rransform it into a document oriented format, and<\/span><\/li>\n
            • write it to the target document database.<\/span><\/li>\n<\/ul>\n

              The process ran in stages: the converter retrieved objects and their relationships, then transformed them according to an agreed mapping \u2013 embedding some structures directly in documents and representing others as references between collections.<\/span><\/p> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

              \n
              \n \n\n
              \"A
              Initially, the process of converting the database took\u2026 seven days!<\/strong> This wasn’t good enough, so we made improvements and managed to cut the time down to just 12 hours<\/strong>. And yes, we are really proud of that!<\/figcaption><\/figure>\n\n\n<\/div>\n<\/div>\n\n
              \n
              \n
              \n
              \n

              The tool also handled type conversions, generated new identifiers where needed, and split larger structures into smaller units to <\/span>comply with the NoSQL database engine limits<\/span>. Due to the database size, the whole operation ran in batches to control memory and track progress.<\/span><\/p>\n

              The test database migration process went smoothly<\/strong>. The data was transferred without a hitch, and there were no problems during type conversion. This confirmed that the selected database technology was the right fit for the system\u2019s requirements.<\/p>\n

              \n

              Success at this stage led to migrating the entire database to the new technology.<\/strong><\/p>\n<\/blockquote> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

              \n
              \n \n\n
              \"An
              As a result of our cooperation, the final size of the database was reduced by approximately four times<\/strong>.<\/figcaption><\/figure>\n\n\n<\/div>\n<\/div>\n\n
              \n
              \n
              \n
              \n

              Step 3: Swapping the database inside the system<\/h3>\n

              With the new database ready, we adapted the system to use the new database engine.<\/span><\/p>\n

              \n

              The good news: the system already had a data-access abstraction layer<\/strong> separating business logic from the concrete database, and it was applied quite rigorously \u2013 though there were spots with direct database calls.<\/strong> <\/span><\/p>\n<\/blockquote>\n

              The data model was implemented as Java classes that also depended on interfaces and base classes provided by the object-database driver. Removing those dependencies was one of our tasks.<\/span><\/p>\n

              We began by auditing all places where the system talked to the old database. Based on this, we defined clean interfaces at the boundary between application logic and data storage. Next, we implemented those interfaces for the new NoSQL database, using advanced Java mechanisms such as reflection and aspect-oriented programming. This kept changes to existing code relatively small and minimized edits to business logic.<\/span><\/p> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

              \n\n
              \n\n
              \n\n\n \n
              \n\n \n
              \n
              \n \"1704982341607.jpg\"\n <\/div>\n\n
              \n

              \n \u0141ukasz Warcha\u0142 <\/h4>\n \n \n CTO @NubiSoft <\/span>\n <\/div>\n <\/div>\n \n \n \n The hardest part was faithfully replicating the old engine\u2019s behavior \u2013 especially search and sorting \u2013 so that the system using the new database behaved exactly as before. <\/q>\n\n \n <\/div>\n <\/div>\n <\/div>\n\n<\/div>\n\n
              \n
              \n
              \n
              \n

              Automated tests were key: we ran them in parallel on both versions and quickly found and fixed any differences.<\/span><\/p>\n

              \n

              We followed the rule <\/span>\u201cMake It Work. Make It Right. Make It Fast.\u201d<\/b><\/p>\n<\/blockquote>\n

              First, we plugged the new database into a few UI views. With feedback from manual and automated tests, we fixed bugs and edge cases. Finally, we optimized performance: using a profiler to find slow spots, then tuning code paths. Knowing real-world read\/write patterns, we also added caching.<\/span><\/p>\n

              Once we hit the required performance and functional parity, we moved to deployments. The new app version was immediately used for new customers, while existing installations were migrated in stages: newer ones first (smaller data, lower risk), older long-running ones later (much larger data, requiring extra care). This kept the process smooth and controlled.<\/span><\/p> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

              \n
              \n \n\n
              \"A
              Replacing the database is not just about reducing its size. The solution we proposed affected the entire architecture and enabled horizontal scaling on the end customer’s side.<\/figcaption><\/figure>\n\n\n<\/div>\n<\/div>\n\n
              \n
              \n
              \n
              \n

              Lessons Learned\u00a0<\/b><\/h2>\n

              In this project we built practical know-how for migrating from an object database to a document store while maintaining continuous system operation.<\/span><\/p>\n

                \n
              • Using an existing data-access abstraction in a legacy system<\/b>
                <\/b>We developed an approach that leverages the existing abstraction layer and builds an adapter for the new engine. This limits code changes and minimizes risk of introducing bugs into application logic.

                <\/span><\/li>\n
              • A repeatable migration pipeline (object DB \u279d Document DB)<\/b>
                <\/b>We built an offline Java converter with clearly defined data-model mapping (embed\/reference), type conversions, ID generation, and batch processing of large data volumes. We now have tools and procedures that can be reused for future installations.

                <\/span><\/li>\n
              • Operational playbooks for large on-premise migrations<\/b>
                <\/b>We have hands-on practice running migrations during maintenance windows, tracking progress, validating outcomes, and ready-made rollback scenarios \u2013 focused on continuity of service and minimal downtime.<\/span><\/li>\n<\/ul>\n

                If you’re facing a similar challenge, we can show you how to replace a database in a live production system without affecting application logic or interrupting operations.<\/span><\/p>\n

                 <\/p> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

                \n\n
                \n
                \n\n \n
                \n\n
                \n

                \n Who are we? <\/h2>\n

                \n At NubiSoft, we partner with medical software companies to develop their products by providing specialized IT solutions. If you\u2019re considering adding new features and need assistance, feel free to contact us. <\/p>\n\n <\/div>\n