A new DMS

In 5 steps

Software is static. It becomes outdated, no longer meshes well with your ERP, CRM or financial package and requires updates to meet all the changes. Work environment requirements also change. Corona has made us all aware of the possibilities of working from home and because of this, the working conditions have changed and therefore the software used for the employee. This results in all kinds of new challenges.

DMS (Document Management System) is no different in this. It is software that runs locally or in the cloud and provides a specific set of capabilities. Over time, the world around us changes, but the old familiar DMS still does exactly what it always did: store documents and emails in the files created for that purpose in the same system. Nothing wrong with that, right? Meanwhile, the office has switched to Microsoft365, collaboration is completely different, and employees need a system to match. The old familiar DMS can no longer keep up. It’s time for renewal!

But how do you do that without affecting your production? How do you safeguard the certainties of the old package? And how do you get all users to go along with the change?

Epona takes you through the project approach of implementing Epona365 to show you how we approach this.


Let’s start with the adoption of the new package. Who is it being done for? Exactly! The end user. Right from the start of the project, we involve the end users in setting up the software. After all, to ensure that all requirements are clear, we need to know what they are.

So we put together a project group with a project leader and a test group filled with users from all departments that will be using Epona365. Together with the project manager of Epona, one or more design sessions are scheduled in which the possibilities of Epona365 are highlighted:

  • How is a new dossier created?
  • What information should be reported in a new file?
  • Who should be able to access the dossier?
  • Are there different file types?
  • Which folders should be created per dossier type?

These are some of the questions that need to be answered. By involving the users in this, we create an environment made by – and for – the people who ultimately have to work with it.

Also not unimportant: we let the test group test the result first, so that we know for sure that we are on the right track.


These days, everything is connected to everything. Making coffee with your watch because it “knows” you’re awake, it’s all possible. Software ties all that hardware together and creates new – and sometimes unprecedented – possibilities.

For example, we link Epona365 to your time registration software. You create your file in one of the two and the information is transferred neatly, so that the file only has to be created once.

How it starts: Epona365 runs entirely in the environment (tenant) of Microsoft365. To be precise, in SharePoint Online. During the project, the design is implemented in SharePoint Online by one of our technical consultants. This installation takes place alongside your current production environment, so you can continue to work in your current package.

Once the installation is complete, the test group can test the design. After the test and any necessary adjustments, a date will be agreed on when the transition to Epona365 can be made.

Epona365 is a system that assumes that everyone has access to everything, unless otherwise specified. As an office, you can thus make files accessible to everyone, but also shield files that are confidential. For example, the HR department can also use the DMS knowing that all their files are protected from the rest of the organization.


A migration is a copy of your current data while retaining all the metadata of the original. This metadata is important because this is the information about the files. Think about the date a file was created, or emailed.

Metadata is used much more often than thought. Think about how inconvenient it is if you no longer have the receipt date of an e-mail and therefore the chronological order of your mail is missing.

Epona performs 3 migrations to make sure we migrate all files and all associated metadata correctly. First, we perform a small test migration on a few pre-selected files. We have the test group check the migrated data to make sure we have transferred all files correctly.

Is this migration successful? Then we perform the bulk migration. With this we migrate all the files that are there.

After this migration, we perform the delta migration. This one is very important because it migrates all changes made to the files between the bulk migration and going live. Yesterday’s work is therefore not lost. A delta migration is always performed over a weekend and the following Monday Epona365 goes live. From that moment on, your team works in Epona365 so all changes are written into the new package from that moment on.


Finally, all users need to be trained on Epona365. The test group can play a role in this in a train-the-trainer principle or Epona’s project manager provides the training online or at your office. Regardless of the choice, all users are provided with the right information to get started with Epona365 right away. We provide reference material to fall back on and training sessions are recorded as standard so they can be reviewed at a later date.


We complete a project only after all users are accustomed to the new software. That way, all the knowledge of the project team is available and the users can fall back on it. This ensures peace of mind in the organization and a well-managed transition. Meanwhile, the transfer to Epona’s support is prepared so that – after the conclusion of the project – all questions can be submitted by your users via our support portal.

Do you also want to know how the combination of Epona365 and Microsoft 365 will help you achieve a fully-fledged legal DMS? Download our free white paper “Using Microsoft 365 as a DMS”!