From the Cloud to Your Own Server: ISMS Migration Without Data Loss

Why companies are leaving their cloud ISMS

The decision to adopt a cloud-based ISMS solution is usually made quickly at most companies. No server to set up, no hosting to organize, no admin overhead. Just sign up, enter a credit card, and get started. Three years later, the bill looks different — both literally and figuratively.

The reasons for switching from cloud to self-hosted fall into three categories that almost always appear together in practice.

Cost control

SaaS vendors price per user, per module, or per asset count. What stays reasonable with 5 users and 50 assets becomes a significant budget item with 20 users and 300 assets. The typical progression: in the first year, the ISMS platform costs 3,000 euros. In the second year, modules are added that were not needed during onboarding. In the third year, the provider switches to a new pricing model, and suddenly 8,000 to 12,000 euros appear on the annual invoice.

On top of that comes the limited negotiating position. If your entire ISMS is locked in a system you cannot easily export from, the provider has little incentive to meet you on price. This is not a theoretical problem. In a comparison of actual total costs, self-hosted solutions are often cheaper from the second year onward because license costs do not scale with user count.

Data sovereignty and compliance

For companies subject to NIS2 or pursuing ISO 27001 certification, the question "Where does my ISMS data reside?" is not academic. Your ISMS contains a detailed map of your vulnerabilities, your risk assessments, and your not-yet-implemented controls. It is practically the handbook for where your company is vulnerable. Storing this handbook on a server over which you have no direct control is a contradiction that must be explained, at the latest during an audit.

Some industries go even further. Critical infrastructure operators, companies with classified information requirements, or suppliers in the defense industry sometimes have contractual provisions that preclude storing security documentation outside their own infrastructure.

Dependency and control

Cloud services are convenient as long as they work. But you depend on decisions you cannot influence. The provider changes the API. The provider discontinues a feature. The provider gets acquired and the product is integrated into another platform. The provider has an outage, and you cannot access your documentation right during the audit.

These are not horror scenarios — they are documented business events in the SaaS industry. Those who self-host their ISMS trade the comfort of "someone else takes care of it" for the assurance of "I can rely on my system because it is mine."

Before the migration: Inventory and export analysis

Before starting the migration process, you need clarity on two things: what is in your cloud ISMS, and how do you get it out?

Inventorying the data

Create a complete list of all data types stored in your cloud ISMS:

• Assets and inventory: All recorded IT assets with classification, protection requirements, and responsibilities
• Risk assessments: Risks with threats, vulnerabilities, assessment matrix, and treatment decisions
• Controls: All controls with implementation status, responsible persons, and deadlines
• Statement of Applicability: The SoA with justifications for each control
• Documents and policies: All uploaded or system-created documents
• Audit records: Internal audit reports, findings, corrective actions
• Evidence: Screenshots, certificates, training records
• History and change logs: Who changed what and when

Checking the legacy provider's export capabilities

This is where things often get uncomfortable. Not every ISMS vendor makes export easy, and some make it deliberately difficult. Check the following points:

Pitfall: The incomplete export

The single most common mistake during migration is relying on the legacy vendor's export button without checking the result. A real example: a mid-market IT service provider exported their ISMS from a well-known SaaS platform. The export contained 230 risks as CSV. What was missing: the risk assessment history (what values did the risks have at the last assessment?), the link between risks and controls (only the risks themselves, not their controls), and all file attachments.

Therefore: export a test dataset early and check it against your inventory. Do this at least six weeks before the planned migration date. If the export is incomplete, you need time to find alternatives — whether through the API, through support, or in the worst case through manual extraction.

Phase 1: Preparation and field mapping

Understanding the target system structure

Before moving data, you need to understand how the target system organizes data. Every ISMS tool has its own structure: different field names, different hierarchies, different required fields. What the legacy vendor calls "probability of occurrence" may be called "frequency" in the target system. What was a 5-level scale there may be a 3-level scale here.

Create a mapping document that defines the assignment between legacy and new system for each data type:

Example for risk assessments:

This mapping is detail work that easily takes two to three days. But it is the investment that makes the difference between a clean migration and weeks of rework.

Data cleanup before migration

A migration is the perfect opportunity to clean up. Do not blindly carry over everything from the legacy system:

• Remove outdated risks: Risks referring to systems that have long been decommissioned
• Consolidate duplicate assets: Duplicates often accumulate over time
• Archive completed controls: Controls with status "completed" and a completion date more than two years ago do not necessarily need to be migrated
• Identify orphaned documents: Policies that were never approved or have long been superseded by newer versions

Document what you consciously choose not to migrate and why. This is not a nice-to-have — it is a requirement from ISO 27001, which demands traceable changes to the ISMS.

Phase 2: Export and transformation

Structured export

Perform the export systematically — not all at once, but by data type:

1. Master data first: Users, organizational units, locations
2. Assets: All IT assets with classification and protection requirements
3. Risk assessments: Risks with all assessment dimensions
4. Controls and measures: Including implementation status and responsibilities
5. SoA: Statement of Applicability with justifications
6. Documents and evidence: All file attachments
7. Audit data: Audit reports, findings, corrective actions

Save each export with a date and description. You will refer back to them multiple times during the migration.

Data transformation

The exported data must be converted to the target system's format. Depending on how differently the systems are structured, this can range from simple column renaming to complex transformations.

A script is recommended for the transformation — even if it is just a Python or PowerShell script that renames CSV columns and maps values. The reason: if you find an error during the first import, you can adjust the script and repeat the import. With manual transformation, you start over with every error.

A typical transformation script does the following:

• Rename columns per mapping document
• Transform values (adjust scales, translate text values)
• Replace IDs (legacy system asset IDs with target system IDs)
• Resolve and re-establish relationships
• Add required fields that did not exist in the legacy system

Data formats and compatibility

The most common exchange formats in ISMS migrations:

CSV: Simple, widely used, but loses relationships and hierarchies. Works well for flat data structures like asset lists. Problematic for nested data like risks with multiple linked assets.

JSON: Can represent hierarchies and relationships. Better suited for complex data structures. ISMS Lite offers a JSON import that can ingest assets, risks, and controls with their relationships in a single pass.

XML: Similarly powerful to JSON, but more cumbersome. Less common in practice because most modern ISMS tools prefer JSON.

PDF: Only for human readability. Not machine-readable, not importable. If the legacy vendor only offers PDF exports, you have a problem that requires manual transfer or OCR.

Phase 3: Import and validation

Test import with a subset

Never import the complete dataset in one go. Start with a subset:

1. 10 assets with different classifications
2. 5 risks with different ratings and linked assets
3. 5 controls with different statuses
4. 2 documents as file attachments

Check after the test import:

• Are all fields correctly populated?
• Do the relationships match (risk → asset, control → risk)?
• Are umlauts and special characters correctly displayed?
• Do the rating scales match after transformation?
• Are responsibilities assigned to the correct users?

Correct the transformation script, delete the test data, and repeat the import. Plan for two to three iterations of this cycle.

Full import

After the successful test import, the full import follows. Document the time and create a backup of the target system beforehand (for self-hosted, a snapshot or filesystem backup). The import should take place outside business hours so no other users are working in the system simultaneously.

Validation checklist

After the full import, check systematically:

• Number of imported assets matches the export count (minus consciously non-migrated entries)
• Number of risks matches
• Number of controls matches
• Spot check: 10 random risks with all fields and relationships verified
• Spot check: 5 assets with protection requirements and linked risks verified
• SoA complete and justifications present
• All documents and file attachments readable
• User permissions correctly assigned
• Risk matrix shows plausible distribution
• Audit trail in target system documents the import

Phase 4: Parallel operation

Parallel operation is the safety-net phase. For four to eight weeks, you run the new system in production while the old one remains available in read-only mode.

Rules for parallel operation

• New system is authoritative: All changes are made only in the new system
• Old system is read-only: It serves only as a reference for questions
• Daily reconciliation in week 1: Check every day whether data is missing in the new system that is still visible in the old one
• Weekly reconciliation from week 2: Reduce the check frequency once the data situation has stabilized

What typically surfaces during parallel operation

• Fields that were forgotten in the mapping (especially: free-text notes that were stored in an unexpected location in the legacy system)
• Relationships that were lost in the transformation
• Rating scale transformations that do not work correctly at boundary values
• Documents that were not captured during export

You correct these findings as they arise in the new system. Document every correction so you have a complete migration log at the end.

Phase 5: Decommissioning the legacy system

Formal decommissioning

Decommissioning the cloud service is not a technical event — it is an organizational one. Document it accordingly:

1. Decommissioning decision: Management approval for decommissioning, based on the validation report
2. Final complete backup: A final export from the legacy system as an archive, in case questions arise later
3. Cancellation with the provider: In writing, observing notice periods
4. Confirmation of data deletion: Request written confirmation from the provider that your data has been deleted. This is not just best practice — it is a GDPR requirement when personal data is involved.
5. Documentation in the ISMS: The migration itself is a change to the ISMS and belongs in change management

Decommissioning checklist

• Management has approved the decommissioning
• Final archive export is safely stored (separate storage location, not in the new system)
• All users are informed and have access to the new system
• Credentials for the legacy system are deactivated
• Cancellation has been received and confirmed by the provider
• Data deletion confirmation from the provider is on file
• SSO/SAML integration to the legacy system is removed
• Migration documentation is filed in the ISMS
• IT asset inventory is updated (legacy system removed, new system added)

Complete migration checklist

This checklist summarizes all phases and serves as a project plan:

Preparation (weeks 1-2)

• Data in legacy system fully inventoried
• Export capabilities of legacy provider reviewed and documented
• Test export performed and checked against inventory
• Gaps in export identified and workarounds planned
• Notice periods and transition period with legacy provider clarified
• Target system installed and configured
• Users created in target system

Mapping and cleanup (weeks 3-4)

• Field mapping between legacy and new system created
• Scale transformations defined
• Transformation script created and tested
• Data cleanup performed (duplicates, outdated entries)
• List of consciously non-migrated data documented

Export and import (weeks 5-6)

• Full export from legacy system
• Data transformation performed
• Test import with subset successful
• Full import completed
• Validation passed (counts, spot checks, relationships)

Parallel operation (weeks 7-14)

• New system communicated as authoritative system
• Daily reconciliation in week 1
• Weekly reconciliation from week 2
• Corrections documented and performed
• User training on new system

Decommissioning (week 15)

• Management approval for decommissioning
• Final archive export
• Cancellation with legacy provider
• Data deletion confirmation received
• Migration documentation completed

Common mistakes during ISMS migration

1. Exporting too late

Those who only attempt to export after cancellation are under time pressure. Some vendors delete data just days after the contract ends. Export at least six weeks before the planned decommissioning and review the export thoroughly.

2. Relying on PDF exports

A PDF report of your risk assessment may look good on screen, but it is worthless for migration. You need structured, machine-readable data. If the vendor only exports PDFs, ask for CSV or JSON, or use the API.

3. Ignoring relationships

The real strength of an ISMS tool is not data storage but relationships: which risk affects which asset, which control addresses which risk. If these relationships are lost during migration, you have all the data but no structure. That is barely better than an ISMS in Excel.

4. Not planning parallel operation

The temptation is great to shut down the legacy system immediately once the import is done. That saves money but creates risk: if problems surface in the weeks after migration, you no longer have a reference. The four to eight weeks of parallel operation are insurance worth having.

5. Not treating the migration as an ISMS change

The migration of your ISMS is itself a change to the ISMS. It belongs in your change management, needs a risk assessment (what happens if data is lost?), and must be documented. An auditor will ask about it.

Special topic: Recognizing and avoiding vendor lock-in

Some cloud vendors deliberately make switching difficult. This is called vendor lock-in, and it is one of the strongest arguments for self-hosted solutions. Typical lock-in mechanisms:

• Proprietary data formats: Data stored in a format only the vendor can read
• Limited export functions: Only partial exports possible, critical data types missing
• No API or restricted API: No programmatic access to your own data
• Contract clauses: Data deletion immediately after contract end, no transition period
• Long-term contract commitment: Notice periods of six or twelve months

Before you commit to a new ISMS system, examine these points carefully. The question "How do I get out of here?" is just as important as "What can the system do?" In ISMS Lite, all data resides in open formats on your own server. Export as JSON or CSV is possible at any time, without restrictions and without asking the vendor for permission. Annual costs start at 500 euros, with no user limits and no modules that need to be purchased separately.

After the migration: Ongoing operations

The migration is complete, the new system is running. Now everyday life begins. Two things you should address promptly:

Backup strategy for the self-hosted system

What you did not have to worry about in the cloud, you now must organize yourself: data backup. Define a backup concept for your ISMS system that includes at least daily backups and monthly restore tests. The ISMS contains business-critical data, and a loss would not just be inconvenient — it would be a compliance problem.

Update internal documentation

Update all references to the old system: procedural instructions, training materials, IT documentation, emergency handbook. Nothing is more confusing than documentation that references a system that no longer exists.

Conclusion

An ISMS migration from the cloud to your own server is a project, not a weekend excursion. Plan for eight to fifteen weeks from the first inventory to the decommissioning of the legacy system. The effort pays off if you end up with a system whose data belongs to you, whose costs you control, and that is available when you need it — not when the provider allows it.

Further reading

• Self-Hosted vs. Cloud: Data Sovereignty for Compliance Software
• From Excel ISMS to a Tool: Migration Guide Without Data Loss
• Choosing ISMS Software: What Matters in the Evaluation
• Change Management in ISMS: Managing Changes Safely
• What Does an ISMS Cost? Budget, Effort, and ROI Realistically Estimated