In this new series of Blogposts, we will introduce the people that make Strator what it is. With this first interview, we will be introducing Ulrich Bojko, our Head of Development, by asking him about his experiences at Strator. He shares insights on the importance of experts, reliance on AI, and digital sovereignty.

Since 2025, Ulrich has become a core part of Strator. Despite this relatively young cooperation, Ulrich has proven himself to be a valuable part of the team as a man of many ideas with a rigorous work-ethic and a lot of funny jokes. As a SharePoint expert and a business development enthusiast, Ulrich helps Strator reach a little further every day by developing new tools, carrying out massive migrations, and coming up with new ways in which Strator can help companies turn their information into a competitive advantage.

How did you get started at Strator?

My career at Strator started as an external consultant. I am a SharePoint expert and had been working with SharePoint Online and on-premises since 2008. I usually tell people that I can pretty much make SharePoint do anything that they want it to. I’ve made a ton of different solutions, from contract management and QMS systems to extranets and customer portals. Some of them were completely custom-coded, but more recently they have been based on SharePoint functionalities.

Either way, I started as an external consultant for Strator because clients asked them, “Well, now you have moved all of our data into SharePoint, so can you help us do other things with this SharePoint platform?” Of course, this is a completely different speciality, which is where I came in, and I fell in love with Strator and the people there.

When I first saw Strator, it struck me as probably the most boring company I’d ever been invited to. I mean, these librarian geeks talking about classification models and V-models and validation, and all these insane abbreviations like EQ, IQ, PQ, OQ, and whatnot. I thought, “How do you not just die a little inside every day from working with this? This is like a whole new level of geekiness.”

But once I really dug into it, I realised it wasn’t that boring. The moment you need to move 3 or 4 million files without losing any of them, while having it all under control and being able to prove that you did everything correctly, it starts becoming fun. I’m not only building technical solutions, but I’m also getting my hands dirty in the piles of data.

You’re currently the Head of Development. What does that mean?

I’ve always been fond of business development, even though I was a freelancer for 10–12 years. If I saw an opportunity, an issue, or a requirement at a company that I couldn’t solve, I always liked being the one with the network to do something about it. I also love talking to a lot of companies, not just clients.

When it comes to business development, I love developing ideas into real products or real offerings that a company can deliver, given the capabilities of the team. I just like seeing how we can package it, do sales, and build a network of clients, vendors, and partners. It’s about 50% of what I do, while the other 50% is solving clients’ SharePoint issues or building things for SharePoint.

I also follow European policy and politics quite a bit as part of the business development side of things. I like seeing opportunities in politics and pinpointing them for our business or our clients.

A lot of politicians are talking about digital sovereignty at the moment, for example, and it is something I have been talking about for the past 20 years. Now, with the shifts in the political climate around the US, the need for digital sovereignty is finally showing up on people’s radars. Every conversation between a vendor and a public-sector institution, municipality, ministry, government, or whatever will have digital sovereignty as number one on the agenda.

Good thing I love advising clients on how to achieve digital sovereignty: not by purchasing a licence, but by adapting certain capabilities. Especially when there are so many misconceptions about digital sovereignty caused by so-called “sovereignty washing,” where companies market their product as the magical button to becoming sovereign. People like swiping a card and believing they are digitally sovereign after five minutes. But suddenly, your new sovereignty-solution reaches a certain limit, requiring you to buy an upgrade, or the price just goes up. Before you know it, you’re stuck with a vendor lock-in and are no longer digitally sovereign. This can happen with both open-source solutions and, let’s say, a Microsoft solution. Making sure people see that is also what I want to do by building a network.

You really seem to enjoy guiding and advising as a part of business development.

I really like having that advisory role. These days, that comes with its own difficulties, though, as AI is often used as some kind of advisor. It’s quite risky because it’s very persuasive in guiding everybody towards the same one-stop-shop solution, since the big models are based on American thinking. You could get a European AI, but either way it is going to be based on some kind of model which will guide its answer. If people want actual knowledge, based on years of experience, they still need a person giving them personalised advice. I love doing that because advice is never a one-size-fits-all situation. I love getting familiar with a company and understanding its processes. All that business development, for Strator or for a client, is something I really enjoy. It allows me to use my technical knowledge and my communication skills. Operating between the tech and the boardroom is really where I’m most at home.

Is this over-reliance on AI something you encounter often?

That and the reliance on licensing to get everything in order instead of relying on actual capability or certain structures. AI is an extremely powerful tool, but it is just a tool. It doesn't work without the proper preparations.

People don’t want to focus on the boring parts, like getting their data in order first. That lack of a solid foundation is why you see statistics showing that somewhere between 70 and 95% of AI implementations or AI projects do not actually deliver the value they were expected to. People have stopped relying on specialists and experts because of all the marketing fluff, and because they don’t have time to go deeper. Besides that, AI will always answer in the way it thinks the prompter wants to be answered, which is why it cannot have the same value as an expert.

That is also some advice I would give to readers: think slow. AI is also a bubble, and it is important to know that it can pop. Companies can go bankrupt and AI services can increase in price drastically overnight. If you’re using AI without thinking about it too much, you might eventually start using AI instead of thinking. What do you do when the bubble bursts?

Be very, very careful when replacing people with AI. It is a handy tool that doesn’t have any critical sense, it doesn’t look beyond the parameters you give it, and it might not be as certain as you think it is. It can be the biggest digital sovereignty threat you can have because, suddenly, if it stops working or gives you wrong answers while your business depends on it, what do you do?

In short: think slow, build a workflow instead of only relying on AI, and hang on to those very valuable human values and capabilities in your team during this AI age.

Lastly, is there a project in the (near) future you are looking forward to?

Well, we've been developing these small tools for clients made to increase their digital sovereignty by helping them govern their SharePoint websites. I've been calling them our "Blueprints", and I am very excited to see them come to life. I've been working on a scan we will be using for our Strategic Information Assessment - Lite, and I will soon talk more about something I've been calling "Site Lifecycle Governance" as a part of these Blueprints. We are still working on the Blueprints, but we will release more news about them as time goes on.

In recent years, digital sovereignty has become a central concept in discussions about technology, geopolitics and digital infrastructure. In its publication on the topic, the Danish IT Industry Association describes digital sovereignty as the access and ability to develop, use, protect and maintain critical technologies necessary for economic, security and political independence.

Behind this definition lies the recognition that modern societies are deeply dependent on digital infrastructures and global technology providers. When data, systems and digital services operate within infrastructures that organisations or states do not themselves control, a strategic dependency arises.

Managing technological dependencies is not in itself a new challenge. Organisations have always had to deal with risks such as system failures, supplier dependencies or technological obsolescence. What has changed is the degree of dependency, which today gives the issue a different character.

A large share of organisations’ digital environments is now based on service-based platforms delivered by a small number of global providers. These platforms are often deeply integrated into daily operations and work processes, making them difficult both to replace and to move. Technological dependency therefore becomes both more pronounced and more extensive. It is no longer sufficient to view such dependencies as local IT risks. Instead, they increasingly represent strategic risks. Their management consequently moves into executive management and boardrooms under the heading of digital sovereignty.

The question, then, is what this means in relation to organisations’ documents and information assets.

Digital Sovereignty in Document and Information Management

In this article we explore what digital sovereignty may mean in the context of document and information management. The concept is still relatively new in this context, but it is reasonable to ask whether well-established professional disciplines already contain many of the tools needed to address it.

As described above, the concept of digital sovereignty arises from the recognition of technological dependencies. When organisations depend on technologies and infrastructures they do not control themselves, the question arises of how much influence they actually have over the frameworks within which their digital activities take place.

Ultimately, digital sovereignty therefore becomes a question of control. The central issue is not necessarily whether an organisation can eliminate its technological dependencies, but rather to what extent it can retain control – and freedom of action – over the technologies and infrastructures on which its digital activities depend.

For professionals working with document and information management, the idea of control immediately sounds familiar. In this field, control over information has always been a central concern.

A closer look quickly points to several fundamental elements of what control over organisational documents actually consists of.

The first is overvew.

Overview of Information Assets

In practice, organisations store documents in many different places. They may be located in collaboration platforms, case management systems, quality management systems and other specialised applications. They may also be stored in shared drives or in document libraries connected to projects and work processes. In addition, older systems and archives often hold historical documentation.

Having control over documents therefore begins with the ability to form a coherent overview of this information landscape. The organisation must know where its documents are located and which systems and technologies they depend on.

In practice, such an overview also requires the organisation to define the types of documents it actually holds. Without an understanding of what the information consists of, it becomes difficult both to map and manage it.

Which Documents Are Important?

However, an overview of documents is not sufficient in itself. Organisations produce large quantities of documents, but not all of them have the same significance.

Some documents serve primarily a temporary role in work processes – for example drafts or working notes. Other documents have far greater importance for the organisation. These may include contracts, regulatory documentation, quality system documentation, project decisions or technical documentation related to products and intellectual property.

When documents serve such functions, they act as documentation of the organisation’s activities and decisions. It is therefore essential that they remain usable in that capacity. Control over information assets therefore also involves knowing which documents have this status.

The Context of Documentation

In information science, such documents are referred to as records, and their continued value as documentation depends on proper handling.

Records management standards, including ISO 15489, describe this through concepts such as authenticity, integrity, reliability and usability.

The credibility of documentation depends to a large extent on the context in which it exists and the processes it has undergone. This context may include information about who created the document, when it was approved, what role it played in a process, or which versions existed along the way. Classification, metadata and version history can therefore be crucial to how a document is understood and used as evidence.

Documentation must be preserved in a way that makes it possible to understand what the document is, where it originated, and what role it played in the organisation’s activities.

When dealing with records, control therefore concerns not only the document files themselves but also the context that makes the documentation meaningful.

Technological Embedding

In practice, this context is often closely embedded in the systems where documents are managed.

Metadata capturing the document’s context is often stored within the system. Version histories are maintained within system functionality. Classification structures and access rights are governed by system logic and data models. A large portion of the information that gives documentation its meaning therefore does not exist independently of the technological environments where documents are processed.

This also means that the value of documentation becomes dependent on these technologies. If a system changes, is phased out or replaced, the organisation’s ability to preserve the structure and coherence of its documentation may be affected.

When analysing what it means to have control over information assets, this adds a technological dimension. Organisations must understand and manage the metadata and processing traces that are essential for their records to retain their documentary value.

What Does Control Over Documents Mean?

Bringing these perspectives together suggests that control over documents in a digital sovereignty context consists of several elements.

Organisations must have an overview of their information assets and know where documents are located. They must be able to distinguish between documents that merely support work processes and those that function as documentation of organisational activities. They must understand the context and metadata that make documentation trustworthy. And they must understand the technological environments on which this documentation depends.

Seen in this light, digital sovereignty in document and information management is not primarily a technological question. It is a question of an organisation’s ability to maintain control over its information assets and their documentary value – even when they are embedded in digital systems and platforms.

At the same time, the analysis points to something else: much of what is described here as responses to digital sovereignty challenges already exists within established professional disciplines. Information specialists, records managers and others who work professionally with information management already deal with overview of information assets, assessment of document significance, understanding of documentary context and management of technological dependencies.

Digital sovereignty in document and information management is therefore not necessarily a new discipline that must be invented from scratch. Rather, it represents a new perspective on a familiar professional domain, where classical disciplines within information management acquire a clear strategic significance.

When an organisation replaces a system, consolidates platforms, or shuts down an older solution, a question about the documents almost always arises: How do we get them into the new system?

If you have not previously worked with document migration, the task may sound relatively straightforward. The files simply need to be moved from one system to another. But that understanding only holds as long as documents are regarded as ordinary files. In practice, documents in organisations are almost always more than that.

For many documents – and especially for those we consider records – the value does not lie solely in the content of the file. The value also lies in the documented context: who created the document, when it was approved, which case or process it belongs to, and which version is the valid one. When such documents are moved from one system to another, the task is therefore not simply about moving files. It is about preserving evidence.

Documents Are Not Just Files

A document in a document management system typically consists of several elements. There is the content file itself – for example a Word document or a PDF. But there is also metadata describing the document, as well as relationships to other documents or objects in the system.

Metadata can be relatively simple information such as title or document type. But in many cases metadata also contains information that is crucial for the meaning and credibility of the document. This may include approval information, version history, or its relation to a particular case, product or process.

Documents are also often part of structures and contexts. A document may be one version within a version chain, part of a case file, an attachment to another document, or part of a larger documentation set. These relationships help define the document’s context.

When documents are moved from one system to another, this context must follow them. Otherwise the documents may exist in the new system but without the connections that make them understandable and trustworthy.

Records Require Preserved Context

The difference between data and records becomes particularly clear in this context.

Structured data can often be moved relatively mechanically from one database to another. Fields can be mapped to new fields, and values can be transformed according to relatively clear rules.

Documents and records behave differently. Here, metadata is not merely a technical attribute but part of the document’s evidential value. If, after migration, it is no longer possible to see who approved a document, when it was approved, or which version was valid at a given point in time, the value of the document as evidence is significantly reduced.

In some organisations this may primarily be a matter of internal trust in the documentation. In others – particularly in regulated environments – it can have more formal consequences. Here documentation may form part of the evidence underlying regulatory approvals, quality management systems or traceability requirements.

This does not mean that all documents require the same level of control during migration. But when documents function as records, the migration must be designed with the objective of preserving their integrity and context.

When Documents Leave Their System

A significant challenge in migration arises at the moment documents leave the system in which they were originally created and managed.

In the original system, the structure, metadata and relationships of documents are typically managed by the system’s own logic. The system knows how versions relate to each other, how documents connect to cases or processes, and which metadata fields are mandatory. Not least, the content file itself is protected.

When documents are exported, this system logic temporarily ceases to protect them. The documents exist for a period outside their original context. It is during this phase that the risk arises that metadata may be lost, relationships broken, values altered unintentionally – and the content file may become corrupted either through technical error or through malicious interference.

The migration task therefore consists of establishing a controlled process in which the documents – meaning both the content file and the metadata, as well as the relationship between them – remain under full control during their transition from the source system to the receiving system.

This may involve transforming metadata if the new system organises information differently from the old one. But such transformations must be consistent, documented and controlled so that it is possible afterwards to explain and demonstrate how the documents were handled during the migration.

Relationships Must Be Re-Established

Another challenge arises from the relationships between documents.

Documents rarely exist in isolation. There may be multiple versions of the same document, different renditions (for example in different file formats), or relationships to other documents within a case or process.

If such relationships are not handled correctly during migration, the result may be that documents lose their connections to each other. Version trees may be broken, attachments may become detached from their parent documents, and documents may end up without the context that explains their role.

A migration therefore often requires a carefully planned sequence for loading documents into the new system. Original versions must be created before subsequent versions, and related objects must exist in the system before relationships between them can be established.

It is precisely considerations like these that make document migration a discipline in its own right and distinguish it from the migration of structured data.

The Real Purpose of Migration

Viewed from the outside, migration can appear to be a technical exercise: export from one system, import into another.

But if the documents have value as documentation – as records – the purpose is different. The purpose is to ensure that after migration the documents can still be used as trustworthy evidence of what they represent.

This means that it is not enough simply to be able to find the document in the new system. One must also be able to understand its context and trust that it is the same document that previously formed part of the organisation’s processes.

Migration therefore becomes not merely the movement of files, but a controlled transfer of documentation.

Conclusion

In some situations it may be entirely sufficient to copy files from one system to another. If the documents have no particular documentary significance and their metadata does not play an important role, a simple file transfer may be a practical solution.

But when documents function as records, the task changes in nature. It is no longer enough to move the content file alone. Metadata, relationships and the context that make the document trustworthy documentation must also be preserved.

This is why we speak of document migration, not simply file transfer. The real task of migration is not to move documents from one system to another, but to ensure that the evidence contained within them survives the system change.

When Compliance Is Reduced to Documentation

When organisations establish a compliance or governance framework, the work almost always begins with documentation. Policies must be formulated, procedures described, and responsibilities and workflows clarified. This is a necessary and important part of creating a shared foundation for governance.

Once policies have been written, procedures published, documents placed in a system, and relevant employees informed and trained, the implementation phase is largely complete. The organisation has articulated its rules and made them accessible.

But documentation is only the starting point. Regulatory requirements ultimately do not focus on the documents themselves, but on the organisation’s actual actions – and on the ability to demonstrate that these actions have been carried out in a controlled manner.

There is therefore an important distinction between documentation and documented behaviour. Documents can describe how something should be done. Compliance only emerges when the organisation’s actions follow the established guidelines and when those actions leave traceable evidence.

Documents establish the framework. Evidence only arises through the actions and records that demonstrate that the guidelines have actually been followed in practice.

When Governance Shifts from Documents to Actions

Once the foundational documentation has been established, the real work begins. The focus shifts from describing the rules to ensuring that they are followed in practice.

At this stage, it becomes clear that compliance is not primarily demonstrated through policies and procedures, but through the traces left behind by the organisation’s actions. These may include records of approvals, changes in systems, access assignments, or the handling of incidents.

A change control procedure does not in itself create control over changes. A policy on access management does not in itself ensure correct access. And an incident management procedure does not in itself handle a security incident.

Documents describe the expected behaviour. Compliance can only be demonstrated when the organisation’s systems and processes support that behaviour in practice – and when they simultaneously record what was done, by whom and when.

It is within this recorded behaviour that the true evidence of compliance emerges.

Documents Describe – Systems Document

If compliance is not primarily about documents, what is it about? It is about documented control.

In this context, control means that the organisation performs specific actions under defined conditions as part of its processes. The term is used here in the professional sense of a control mechanism – not in the everyday sense of checking something (or someone). Documented control means that these actions can be demonstrated afterwards.

Documents still play an important role in this context, but in a different way than often assumed. They describe the controls and define the framework for the work. The evidence itself arises from the records of the actions that are carried out.

When a manager approves a document in a system, the evidence is therefore not the document itself. The evidence is the record of the approval: who approved it, when it was approved, and which version was approved. Similarly, in change management it is not the procedure that documents compliance, but the history of assessments, decisions and implemented changes.

Documents establish the framework for behaviour. Evidence arises in the traceable records showing that controls have actually been performed.

Controls in Practice

When looking at organisational control environments, this principle becomes visible in a number of familiar mechanisms.

Approvals are an obvious example. When a contract, report or change is approved, the system typically records who approved it, the time of approval and which version was approved. These records constitute traceable evidence.

The same applies to change control. When changes are registered, assessed and implemented through a controlled process, a history of decisions and actions emerges that makes it possible to demonstrate afterwards how the change was handled.

Access management and incident management function in much the same way. Compliance is not documented through the access policy or the incident management procedure, but through the records showing who received access, which incidents occurred, and how they were handled.

The common characteristic is that evidence arises through the recording of actions.

The Role of Systems

When compliance is understood as documented behaviour, the role of systems becomes central.

Digital systems make it possible to record actions consistently and uniformly. They can ensure that approvals are recorded with identity and timestamp, that changes are not implemented without a documented decision, and that history is preserved through audit trails.

In this way, systems become the framework within which the organisation’s controls are both performed and documented. It is this traceability that makes it possible to review afterwards what has taken place.

Compliance therefore does not arise in the document repository alone, but in the interaction between documents, systems and the actions performed by the organisation’s employees.

From Document Management to Documented Control

Document management is an important discipline because it ensures that the organisation’s policies, procedures and instructions are clear, accessible and version controlled.

But compliance is ultimately not assessed based on the structure of documents. It is assessed based on whether the organisation’s controls are actually performed – and whether they can be demonstrated.

It is therefore documented behaviour that forms the core of a well-functioning control environment. Documents describe how the work should be carried out. Systems and processes create the evidence that it actually happens.