Modernising a Personal Knowledge Base: Cloud Migration, Data Integrity and Recovery

Last Updated on 8 November 2026 at 16:19

Didier Debbaut’s engineering case study of a personally operated knowledge platform, covering more than 200’000 synchronisation objects, multiple desktop and mobile applications, with a controlled replacement of its cloud-hosted synchronisation service.

Engineering case study · Personal knowledge base (PKB) infrastructure project · Architecture, migration and operational recovery · October 2026

Executive summary

• This case documents the modernisation of my personally operated knowledge infrastructure: a local-first information repository synchronised between desktop and mobile applications through a cloud-hosted service. The system had accumulated more than 200’000 synchronisation objects, including notes, attachments and associated metadata. At the point of my intervention, its operating platform and runtime dependencies had fallen behind their supported generations.
• I assessed whether to rehabilitate the legacy installation through a lengthy succession of upgrades, transfer the repository to a fresh supported deployment, or change the underlying knowledge application and operating model. I chose a controlled replacement of the synchronisation service while preserving the existing application and data structure. The migration transferred approximately 33.5 GB across 359’622 filesystem files. A subsequent comparison found no further files to copy, and the replacement service’s index completed with no reported errors.
• The file transfer was only one part of acceptance. During device reconnection and operational validation, three issues required intervention: a runtime resource limit insufficient for the repository’s synchronisation workload; deletion requests initiated by a long-disconnected mobile client; and a backup-retention operation that had failed despite a successful summary notification. The 69 identified missing attachments were recovered from the retained source copy, and the affected operating controls were revised.
• The result was a supported replacement platform at the time of the intervention, functioning synchronisation on the devices tested, recovered attachments, improved operational checks and a documented maintenance path. A full application-object reconciliation and end-to-end disaster-recovery exercise were not completed in the evidence available for this report. Those limits remain explicit.

PKB project profile

1. Initial condition: a PKB system with substantial operational dependencies

The repository contains knowledge and reference material accumulated over 22 years years of daily use. The knowledge application retained its working data locally, while a cloud-hosted synchronisation service made that information available across several devices. Notes and their attachments had become a substantial, interconnected collection. A user could edit content on one device and expect the current state to become available elsewhere. Even everyday retrievals, such as opening a saved recipe on a mobile device, depended on reliable synchronisation.

This convenience disguised several maintenance obligations.

• Maintenance had been deferred while the synchronisation platform and its runtime dependencies continued to age.
• Compatibility constraints between the legacy application and supported runtimes complicated the upgrade path.
• Some non-default settings lacked a recorded explanation; and local devices did not all hold equally recent views of the repository.
• The existing backup arrangements also needed review against what they actually protected and how their success was verified.

The size of the repository influenced the architecture.

More than 200’000 synchronisation objects describe application-level items.

The 359’622 filesystem files describe the files transferred during migration.

Those numbers are different counts, representing different layers of the system. Neither number should be described as the number of independent notes or documents.

The essential engineering requirement was continuity of usable knowledge.

A replacement service would have little value if it preserved the directory tree but allowed references to attachments to break, stale client state to overwrite current information, or backup jobs to report success without delivering their intended results.

For a single user, the operational exposure is personal rather than corporate.

Yet, in both situations, the questions remain very pragmatic: what data is authoritative, which device can modify it, how a migration is accepted, what evidence supports recovery, and who will maintain the platform when the immediate project is over ?

2. Architecture decision: upgrade, replace the service, or change the operating model

I assessed three options against the knowledge-base requirements, continuity constraints and recovery risks.

The selected path deliberately limited simultaneous change.

I wanted to remove the unsupported service dependency without introducing an additional knowledge-application migration into the same recovery window.

The transfer method was chosen because the relevant synchronisation target stored the application items as files whose relationships could be preserved, with the destination platform able to rebuild its own file index. That was a characteristic of this particular architecture. The selected method was specific to this file-based synchronisation target and it did not justify copying arbitrary application directories beneath an active database. Other systems depend on transactional relationships, permissions, external identifiers or database-managed state that must be migrated through their own supported procedures.

A retained copy of the previous repository was therefore part of the cut-over design.

Its immediate purpose was selective recovery if something went wrong. It should not be described as a proven full-service rollback: restarting the complete former service had not been demonstrated in the supplied acceptance record.

3. PKB migration execution and verification

Baseline and pre-flight checks

The preparation established the actual data volume and the relevant dependencies like the following:

• supported runtime choices,
• application prerequisites,
• synchronisation data layout,
• device state,
• scheduled operations
• and recoverability.

The inventory reduced the risk of copying material that belonged to the legacy installation but was not part of the active synchronisation repository.

I also treated background and automated writers as part of the change boundary. A user-facing application that appears closed is not sufficient proof that every device, task or service has stopped changing the source. The participating clients were synchronised and stopped before the data transfer, and source-side activity was checked during the freeze.

Transfer and file-level reconciliation

The dataset was copied within the hosting environment while preserving the attributes required by the chosen method. The operation transferred 33.5 GB and 359’622 files in 1 hour 52 minutes. A dry-run comparison subsequently reported no additional changes to transfer. Source and destination file counts matched.

The destination index then completed in 4 minutes 7 seconds, with zero reported indexing errors.

Selected file sizes and modification times were compared with the source. These observations supported acceptance of the file-level transfer and indexing stage. They did not amount to a cryptographic verification of every byte, nor to a complete application-level reconciliation of every note and attachment reference. The scope of the controls should not be overstated.

First controlled synchronisation-client validation

Device reconnection was performed in stages. After correcting the runtime issue, a recently synchronised desktop application connected to the replacement service without requiring a bulk upload or download. A test note created on the desktop appeared on a mobile application; a subsequent edit on the mobile application was then observed on the desktop.

These checks demonstrated bidirectional synchronisation for the applications tested. Other device profiles, particularly those with outdated local state, still required separate validation before being permitted to resume normal synchronisation.

That distinction became central to the next incident.

4. Investigated incident: runtime capacity did not match the synchronisation workload

The first attempted desktop synchronisation failed with a server error.

The diagnostic record indicated that the service exhausted the resource allowance available for the request it was processing.

The legacy deployment had a substantially larger non-default allowance. During initial preparation, I had treated that setting as a candidate for simplification without first establishing the workload that had required it. The large object inventory made that assumption consequential: preparing synchronisation responses for a repository of this scale was more demanding than serving an ordinary application page.

Restoring an appropriately sized resource allowance allowed the client to complete its synchronisation check. The corrective outcome was more than a configuration change. The operating notes now needed to explain why non-default parameters existed, which workload justified them, and what evidence would support changing them later.

5. Investigated incident: a long-disconnected synchronisation client altered current repository state

The more consequential incident emerged after the replacement platform was operating. A mobile device that had not synchronised for an extended period returned with an outdated local view of the repository. It initiated deletion operations affecting 69 attachments still referenced by 13 current notes.

From the synchronisation service’s perspective, these were requests from an authorised device. The server’s successful migration did not establish that every returning synchronisation client held an accurate view of the current repository state. The outdated client state had therefore become a separate source of operational risk.

The deletion operations were identified in the available access records, and the affected client was stopped. The retained source repository contained the identified missing resources. A targeted comparison identified the missing resources. I restored only those attachments from the retained source repository, without overwriting current content, and then re-indexed the restored files.

The 69 identified attachments were reported recovered. The affected mobile profile was reinitialised and permitted to download the current repository. That initial rebuild took approximately 16 hours, including interruptions inherent to mobile operation.

This supports a specific recovery result. It does not establish that every application object was independently checked, that no unrelated discrepancy existed, or that the complete service could be restored from backup. The old dataset was successfully used as a selective recovery source.

The resulting procedure gives returning devices an explicit admission check. Their last known synchronisation state, possible unsynchronised local changes and capacity to issue destructive operations must be assessed before write access resumes. Any proposed reset must first preserve and inspect local material that might exist nowhere else. A stale client should not be treated as a passive reader of the new server.

An authorised client with obsolete state can introduce a new inconsistency into a correctly transferred repository.

6. Investigated incident: backup reporting did not verify retention

The former backup arrangement required improvement because operational evidence and recoverability were insufficiently clear. The replacement procedure introduced clearer error handling and a report of its execution. Its initial summary indicated success, while the detailed record showed that the retention-cleanup step had not completed as intended in the unattended environment.

The immediate transfer and archive operations were therefore not the entire definition of success. If old backup sets had continued to accumulate without being removed, storage consumption could eventually have threatened the service. The reported outcome and the retained storage state had diverged.

I corrected the cleanup behaviour and added an explicit post-operation check. The job’s verdict now depends on the actual number of retained sets, rather than merely on whether the cleanup command was attempted.

Separate off-server backup coverage was checked for the relevant application files and database. That provides evidence about the materials included in the provider’s backup arrangement. No complete restore of the new service from that backup chain was performed as part of the recorded case. The targeted recovery of the 69 attachments is not a substitute for that exercise.

Retirement of an obsolete archive set reclaimed approximately 31 GB of storage. Further potential savings associated with retiring the preserved old instance were not yet realised and are not included in the reported result.

A successful notification cannot be used as evidence for a step the job has not independently checked.

7. Results and evidence assessment

The outcomes below are drawn from my October 2026 records. They are operator-reported observations from my personal KB infrastructure project, rather than independently reproduced audit results.

The measured copy and indexing stages completed without reported errors, while later devices and scheduled-operation checks revealed defects that were outside those stages’ acceptance scope. That is why I would not describe the result simply as a “successful migration with no data loss.” The defensible record identifies what passed, what had to be repaired and what remains untested.

8. Engineering interpretation: what the intervention changes

Data ownership requires more than storage ownership

A local-first application can preserve a useful degree of control over its information while still depending on a remote synchronisation endpoint, its runtime, its scheduled maintenance and each participating client’s state. Operating the service personally does not remove those dependencies. It makes their ownership explicit.

The architecture should be documented in terms of where authoritative information resides, which components can modify it, what evidence confirms consistency and how it can be recovered. Product names alone are a poor substitute for that map.

Migration acceptance needs several separate decisions

The case revealed four different acceptance levels: data copied; application state usable; day-to-day operation dependable; recovery demonstrably possible. Passing one does not automatically close the others. A matching file inventory supported the transfer. A two-way synchronisation test supported client usability. Corrected retention checks supported an operating control. A full disaster-recovery test remains outstanding.

This same separation appears in knowledge-management and delivery-governance work at much larger scale. In my earlier Creating a Knowledge Base with ServiceNow case, the technical system was only one part of the problem: publication states, attachments, version navigation, visibility and ownership also had to be structured. The operating context was different, but the dependence of useful knowledge on governed state is common to both cases.

Documentation should explain decisions, while controls verify their execution

The migration notes now have to record the reason for non-default runtime settings, the sequence for admitting returning clients, the acceptance evidence for transfer and synchronisation, and the exact difference between a recovery copy and a tested restoration path.

Some rules belong in documentation while others must be checked when the operation runs. I write about this distinction in another related older publication: Moving Technical Conventions into Code: Why Documentation Alone Does Not Prevent Regressions. The backup-retention correction here is a practical example: explaining that obsolete archives must be removed was insufficient until the routine checked the retained result.

The same evidence discipline is relevant to issue handling and qualification workflows. My earlier JIRA Support Qualifications by R&D — Case Study addresses how operational work can be structured and qualified.

AI-assisted verification under read-only constraints

I performed the changes myself.

In this particular case, I used an AI assistant to examine selected logs, configuration information and comparison outputs with read-only access. This helped provide an additional check without allowing the reviewing assistant to alter the infrastructure it was assessing.

That separation was useful, but it was not an independent human four-eyes approval. The reported measurements come from my operating records, and the final acceptance remains my responsibility. An AI tool’s ability to inspect the evidence does not establish institutional independence or remove the need to validate the claims.

9. Remaining PKB architectural constraints and operational work

The replacement service addressed the immediate support and migration problem but it did not remove every long-term architectural constraint.

Synchronisation of a very large repository can still incur substantial overhead when a device-client or server must enumerate many remote items. The reported improvement in typical desktop synchronisation time is useful operational evidence, but it does not eliminate the underlying workload. A different synchronisation backend or a revised deployment model may eventually be justified, after separate functional, cost, security and recovery evaluation.

A complete restoration exercise using the maintained backup chain also remains to be performed. That exercise should verify recovery of the service and its data relationships, not merely the presence of archives. Maintenance should include an explicit support and compatibility review rather than depending on another emergency migration years later.

Additional engineering considerations

File-count overhead and I/O efficiency. The repository contained approximately 33.5 GB distributed across 359,622 filesystem files. Transferring many small objects creates additional filesystem operations, metadata processing and directory traversal. Elapsed time depends on file-size distribution, storage performance, transfer method and system overhead. The recorded transfer duration of 1 hour 52 minutes is an observation from this particular environment, rather than a general performance benchmark.

Synchronisation and object enumeration. The large application-level object inventory also affected synchronisation behaviour. Depending on protocol and implementation, a client may need to enumerate, compare or request metadata for many remote items. Network latency, request overhead and service-side processing can dominate the operation even when relatively little content has changed. Alternative synchronisation architectures may reduce this overhead, but they require their own compatibility and recovery evaluation.

Logical relationships and application integrity. The dataset contained related application objects, including notes, attachments, notebooks, tags and associated metadata. Preserving physical files was necessary, while application-level testing was required to establish whether those objects remained usable and their references intact. This explains why file-count reconciliation and representative cross-device tests were treated as separate acceptance controls.

Finally, future re-admission of a long-absent client should begin with a protected assessment of its local state. Deleting or resetting the client before preserving unique unsynchronised material could create a different form of loss. The correct decision depends on the evidence available on that device.

10. Relationship to earlier knowledge and governance projects

Although this was a personally operated system, the migration encountered technical challenges also found in larger organisational environments with aspects such a substantial object inventory, ageing runtime dependencies, cross-device state inconsistencies, data-integrity checks and operational recovery requirements.

Its business exposure, number of stakeholders and governance obligations were different from those of an enterprise programme. The relevance lies in the engineering methods applied: establishing a reliable baseline, evaluating migration alternatives, controlling change, examining failures and verifying recovery outcomes.

These methods also connect to several earlier knowledge-management, software-delivery and my governance projects documented on my LinkedIn profile.

1. Creating a Knowledge Base with ServiceNow documents the organisational and operational requirements of an implemented knowledge base: versioned content, publication governance, controlled access and attachments.
2. The related JIRA Support Qualifications by R&D case concerns operational classification and controlled workflows.
3. Another JIRA & Confluence Implementation Case Study: Innovating for Success addresses centralised information and coordinated innovation management.
4. Knowledge Base with ServiceNow portfolio case provides a governance and organisational perspective on knowledge-base implementation.

Together these studies illustrate distinct engineering and strategy contexts: personal information continuity, enterprise service knowledge, issue-handling workflows and strategic governance of shared information. Their scopes and results should be evaluated separately.

CTS-EMEA Review & Closing Assessment

From the perspective of CTS-EMEA, this case illustrates how a personally operated knowledge infrastructure can present engineering challenges familiar from larger technology modernisation programmes.

The intervention undertaken by Didier Debbaut addressed an ageing synchronisation platform, significant data volumes, application dependencies and operational recovery requirements. The controlled migration of approximately 33.5 GB across 359’622 filesystem files, followed by targeted recovery of 69 attachments referenced by 13 notes, demonstrates the practical value of preparation, technical diagnosis, selective restoration and disciplined change execution.

The most significant finding, however, concerns the distinction between technical completion and operational acceptance.

A successful transfer establishes that data has moved according to the controls applied. It does not automatically demonstrate that the application remains consistent, that every connected device holds a reliable view of the information, or that unattended maintenance and recovery procedures function as intended.

The incidents documented in this case exposed precisely these boundaries. An inherited runtime configuration proved necessary under the actual synchronisation workload. A long-disconnected application introduced destructive operations against otherwise current data. A backup routine reported success without having completed its retention requirements.

Each issue required a different form of investigation, corrective action and verification.

CTS-EMEA’s engineering conclusions

The case supports five practical conclusions:

1. Architecture decisions must account for operational dependencies. Application versions, runtimes, data structures and inherited configurations form part of the migration risk assessment.
2. Data migration and application integrity require separate acceptance evidence. File-level reconciliation, application behaviour and cross-device consistency answer different technical questions.
3. Synchronisation state is an operational risk in its own right. A previously authorised application returning with outdated information can compromise the consistency of an otherwise correctly migrated repository.
4. Operational controls must verify outcomes. A successful task notification is insufficient when critical secondary operations, including backup retention, have not been checked.
5. Recoverability must be demonstrated at the appropriate level. Targeted file restoration, verified backup coverage and full-service disaster recovery are distinct capabilities. The final capability was not demonstrated within this project’s recorded scope.

The work also illustrates a measured use of AI-assisted engineering review. Read-only examination of selected technical evidence supported the operator’s investigation while preserving human control over system modifications and acceptance decisions. This represents a useful separation of responsibilities, although it does not constitute independent human four-eyes approval.

Relevance beyond the personal KB infrastructure

The project was independently undertaken by Didier Debbaut for his own private knowledge environment. Nevertheless, the engineering disciplines demonstrated here are directly relevant to legacy platform modernisation, knowledge infrastructure consolidation, software migration, operational resilience and technology recovery.

CTS-EMEA’s overall assessment is that the principal value of this case lies in its evidence-based engineering approach and the operational controls established during recovery. The documented limitations are integral to that assessment: they distinguish what was demonstrated from what remains to be verified.

For organisations confronting comparable technology lifecycle, migration or recovery challenges, ConsultingTeam.Solutions provides the engineering and delivery perspective. The wider implications for governance, accountability and strategic execution are addressed through the Debbaut.Solutions execution and transformation portfolio.

• Find more about
• Recent Posts

Didier Debbaut

Invited Author (fintech software expert) – Wealth Management

https://www.linkedin.com/in/didierdebbaut/

dd@consultingteam.solutions

FinTech Wealth Management expert with 30 years of successful track record, from Unicible/BCV to Odyssey and Temenos, plus hundreds of important banks across EMEA, APAC, and NAM.

► Background — from C-language code to C-suite in 30 years

• WealthSuite Triple’A Temenos TAP Plus expert
• crisis & change management
• complex multi-level project – program – portfolio management
• process architecture & governance, process optimization, BPO
• financial services software engineering FS FinTech

Career start as an innovative software engineer in startups ► to strategic advisory & turnaround for Tier1 & Tier2 Banks at senior C-level.

• T-shaped mastery of the latest key technologies, business, and operational practices in retail banking, asset management, core banking, PMS.
• Keen focus on improving productivity, client retention, and revenues through expertise in Program Management, Process Governance, and Optimized Delivery, augmented by know-how in complex issue resolution and value-driven E2E end-to-end implementations.

Temenos Practitioner accredited across WealthSuite and FrontOffice domains (FO, PM, TTI). Certified modules include Scripts & Formats, Implementation Methodology (T3TIM), Channels PM, APA Attribution, Constraint Management, Order Management, Data Security, WealthSuite Portfolio Management, and T24 Triple’A Interface. The Practitioner status anchors Didier’s capacity to operate as a Transformation Director, bridging certified product mastery with execution governance and program recovery.

---

Disclaimer —

The views and opinions expressed in this publication are those of the author, Didier Debbaut, and do not represent the views, positions, or policies of Temenos AG, its affiliates, clients, or partners. All information is shared in good faith and in the spirit of professional exchange, as part of an open, constructive contribution to the FinTech and WealthTech community.

Any technical references, opinions, or analyses are based solely on publicly available information and the author’s independent field expertise. They are offered for general informational and educational purposes only.

No confidential, proprietary, or non-public information related to Temenos products, clients, or business operations is disclosed or implied.

© Didier Debbaut — All rights reserved.

• 

  Modernising a Personal Knowledge Base: Cloud Migration, Data Integrity and Recovery

  7 November 2026

  An independent engineering case study of a personally operated knowledge platform containing more than 200,000 synchronisation objects. Didier Debbaut examines architecture decisions, cloud migration, data integrity, client-state recovery, backup verification and the operational lessons from a complex personal infrastructure modernisation.

• 

  Resilience by Design: High Availability (HA) vs Fault Tolerance (FT) in Azure Architectures

  5 October 2025

  Learn when to choose High Availability, Fault Tolerance, or Disaster Recovery in Azure. Didier Debbaut maps costs, risks, and execution trade-offs.

• 

  The Great Debate: Waterfall vs. Agile in Software Development and Project Management

  21 September 2023

  Mixing #Agile with #Waterfall ? Think of it as a cake with the chocolatey structure of Waterfall and the creamy flexibility of Agile. The cherry on the cake is the best of both worlds, and this is how you can win at #software #development and #project #management.

• 

  The Paradox of Agile and Waterfall: An Integrated Approach to Project & Program Management in FinTech Wealth Management Software

  21 September 2023

  The debate between Agile and Waterfall is not a zero-sum game. Each methodology has its merits and drawbacks, and the choice between the two is often dictated by the specific requirements and constraints of a project or program. However, for projects that demand both structure and flexibility, a hybrid approach can offer a balanced solution.

• 

  Project Management & DevOps: Why Waterfall and Agile Need Each Other

  16 September 2023

  In practice, it is not about choosing between Waterfall and Agile; it’s about knowing when to use each. Structure and flexibility are complementary and not mutually exclusive. So, the next time someone tries to sell you on the “one true methodology”, remember: the most innovative solutions often come from combining the best of multiple worlds. It’s not about only waterfall or agile, but a lot of other methodologies, too.