From Excel ISMS to Tool: Migration Guide Without Data Loss

Why the switch is overdue

Excel is an excellent tool. For spreadsheet calculations, for quick analyses, for ad-hoc lists. But Excel is not an ISMS tool, and at some point that becomes painfully obvious.

You probably know the typical symptoms: the risk analysis consists of a file with 15 worksheets and 200 rows per sheet. When the ISM is on vacation, nobody dares touch the file because the formulas are so complex that one wrong click could wreck half the assessment. The controls tracking lives in a separate file that must be manually reconciled with the risk analysis. The Statement of Applicability is yet another document, and the link between SoA, risks, and controls exists only in the ISM's head.

Then there are the structural problems. Versioning in Excel is effectively impossible: who made what change when? Concurrent editing leads to conflicts. Permissions can't be meaningfully controlled. And when an auditor asks how the risk assessment process is traceably documented, you point to a file named "Risk_Analysis_v14_final_FINAL_new.xlsx" — and you know that's not a good moment.

The decision to adopt a specialized tool is the right step. But the migration itself is a project that requires preparation. This guide walks you through the entire process.

Phase 1: Inventory and data cleanup

Identify all sources

Before you migrate a single record, you need to know what you have. And in most cases, that's more than expected. A typical Excel-based ISMS doesn't consist of one file but an entire ecosystem:

• Risk analysis (one or more Excel files)
• Asset inventory (possibly integrated in the risk analysis, possibly separate)
• Controls plan (separate file or worksheet)
• Statement of Applicability (separate document)
• Policies and documents (Word files in the filesystem or SharePoint)
• Audit reports and findings (Word, PDF, or Excel)
• Training records (Excel list or HR system)
• Incident documentation (emails, tickets, Excel)

Create a complete list of all sources. Search file shares, SharePoint, email inboxes, and local drives. Ask the people involved whether they have their own copies or supplementary documents. It's not uncommon for the system administrator to maintain their own asset list that doesn't match the official one.

Check data quality

Once all sources are identified, comes the uncomfortable question: how current and complete is the data? Go through each source systematically and assess:

Currency: When was the file last edited? Are there entries that are obviously outdated — such as assets that no longer exist or risks that relate to decommissioned systems?

Completeness: Are mandatory fields missing? Are there risks without assessments, assets without protection needs, controls without a responsible person or deadline?

Consistency: Do the data match across files? If an asset appears as "ERP system" in the risk analysis and as "SAP S/4HANA" in the asset inventory, that's a consistency problem that must be resolved before migration.

Duplicates: Are there duplicate entries? In organically grown Excel lists, duplicates are almost inevitable, especially when multiple people have worked on them.

Cleanup before migration

The temptation is great to migrate everything as-is and postpone cleanup to "after migration." Don't do this. Importing dirty data into a new tool doesn't make cleanup easier — it makes it harder, because the data now sits in a new context and the connections are harder to trace.

Clean up before migration:

• Delete obviously outdated entries (with documentation of what was deleted and why)
• Merge duplicates
• Fill in missing mandatory fields where possible
• Standardize names and categories
• Flag entries where currency is unclear for later review

This step typically takes one to two weeks depending on the size of the ISMS. That time is well invested, because you'll save it back many times over later.

Phase 2: Create the field mapping

The heart of the migration

The field mapping defines which column or field in your Excel spreadsheet corresponds to which field in the new tool. That sounds trivial but isn't — because the data models rarely align one-to-one.

An example from practice: your Excel risk analysis might have a column "Risk description" that contains the threat, the vulnerability, and the potential impact all in one free-text field. The new tool has three separate fields for these: "Threat," "Vulnerability," and "Impact." This means you need to split the free text — which can't be done automatically and requires manual work.

Typical mapping scenarios

1:1 mapping: Excel column "Asset name" corresponds to tool field "Name." That's the easy case.

1:n mapping: One Excel column must be split into multiple tool fields. Typical for free-text fields containing multiple pieces of information.

n:1 mapping: Multiple Excel columns are combined into one tool field. Less common but does occur, for example when the tool has a comments field that absorbs multiple Excel columns.

Transformation: The value must be converted. For example: in Excel, the likelihood is stored as free text ("rare," "occasional," "frequent"), but the tool expects a numeric value (1-5). Or: in Excel, the date reads "Q2/2026," but the tool needs an actual date.

Missing fields: The tool has fields that don't exist in Excel. In this case, you need to decide whether to add the fields in Excel before migration or fill them in after migration in the tool.

Document the mapping

Create a mapping table that assigns each Excel column to the corresponding tool field for each data area (assets, risks, controls) and documents the type of mapping (1:1, 1:n, transformation). This table is your reference for the entire import and will also be needed for quality assurance after the import.

Phase 3: Determine the migration sequence

Respect dependencies

ISMS data is interconnected. A risk relates to an asset. A control addresses a risk. An SoA entry references controls. These dependencies determine the migration sequence:

Step 1: Master data and catalogs. Categories, assessment scales, roles, locations. This data forms the framework on which everything else is built.

Step 2: Assets. The basis for risk assessment. Each asset gets a unique identifier in the new tool, which serves as a reference for subsequent steps.

Step 3: Risks. Linked to the already imported assets. The risk assessment (likelihood, impact, risk value) is transferred.

Step 4: Controls. Linked to risks and assets. Status, responsible person, deadline, and evidence are transferred.

Step 5: Statement of Applicability. Linked to controls and Annex A items. Since the controls are usually pre-loaded as a catalog in the tool, the SoA is often the easiest part.

Step 6: Documents and evidence. Policies, audit reports, training records. These are typically uploaded as files and assigned to the corresponding areas.

Verify each step

After each migration step, check the imported data in the tool:

• Does the record count match? (Compare Excel row count with tool records)
• Are the links correct? (Spot-check 10-20 records)
• Are the values correctly transferred? (Especially for transformations)
• Are special characters, umlauts, and formatting preserved?

Only when a step is cleanly verified does the next one begin. This prevents errors from propagating through the entire migration.

Phase 4: Execute the import

Technical import options

Depending on the tool, various import paths are available:

CSV/Excel import: Most ISMS tools offer import from CSV or Excel files. You upload a file and map the columns to tool fields. This works well for simple data structures but hits limits with complex linkages.

API import: Some tools offer a REST API through which data can be imported programmatically. This is worthwhile for large data volumes or when you want to automate transformations, but requires programming skills.

Manual import: For small data volumes or complex structures, it can be more efficient to enter the data manually. That sounds like a step backward but has the advantage that you re-examine each record during import and evaluate it in the context of the new tool.

Hybrid approach: In practice, a middle path has proven effective. Bulk, structured data like assets and risk assessments are imported via CSV. Complex, linked data like controls with evidence and documents are entered manually.

Common import problems and solutions

Character encoding: Excel saves CSV files by default in the operating system's encoding, which can cause problems with German umlauts. Always export CSV files as UTF-8 and check after import whether umlauts display correctly.

Date formats: Excel and the tool may interpret dates differently (DD.MM.YYYY vs. YYYY-MM-DD). Standardize the format before export.

Links: When risks reference assets, the import needs a common reference — such as the asset name or an ID. Ensure this reference matches exactly in both files, including capitalization and spaces.

Empty fields: Clarify in advance how the tool handles empty fields. Some tools insert default values; others reject the import.

Phase 5: Parallel operation

Why you shouldn't switch immediately

The temptation is great to switch to the new tool immediately after a successful import and shut down Excel. Resist this temptation. A parallel operation period of four to six weeks gives you the assurance that no data has been lost and that the new tool works in daily operations.

During parallel operation, you enter new records (new risks, new controls, status changes) exclusively in the new tool. The old Excel files are frozen — no longer edited but kept as a reference. This way, you can compare at any time whether the data in the tool matches the last state of the Excel files.

What to check during parallel operation

Functionality: Can all stakeholders complete their tasks in the new tool? Can they find the information they need? Are the workflows intuitive, or do they need training?

Completeness: Do records surface during daily work that are missing in the tool but existed in Excel? That's a sign of an incomplete import.

Reports: Can the reports needed for audits, management reviews, and senior management be generated from the tool? Do the numbers match expected values?

Performance: How does the tool respond with the data volume of your ISMS? Are there delays when loading or searching?

Training during parallel operation

The parallel operation period is the ideal time for training. Employees can work with the new tool and fall back on the familiar Excel files when unsure. Plan at least one training session for each stakeholder group:

• ISM and core team: comprehensive training on all functions
• Risk owners and controls owners: training on the areas they're responsible for (assessing risks, updating controls status)
• Senior management: brief introduction to reporting and dashboard features

Phase 6: Shutdown and archiving

Formal shutdown

When parallel operation has been successfully completed, the formal shutdown of the old system follows. This sounds trivial but is an important step — because as long as the old files are accessible and editable, they will be used, and then you have two data sources that diverge.

The shutdown involves:

1. Final comparison between tool and Excel
2. Archiving the Excel files with a date stamp (read-only, in an archive directory)
3. Communication to all stakeholders: as of date X, the tool is the sole source for ISMS data. The Excel files will no longer be maintained.
4. Removal of the active Excel files from shared access (don't delete — just move to the archive)

Archiving for compliance

You should keep the archived Excel files for at least the duration of one certification cycle — that is, at least three years. An auditor might ask about the history, and the ability to demonstrate the previous state is valuable. Archive the files as PDF exports in addition to the Excel file, since PDFs are more stable long-term and can't be accidentally modified.

Typical mistakes and how to avoid them

Mistake 1: Migrating everything at once

Anyone who transfers all data in one big import has no way to isolate the error when problems arise. Migrate step by step and verify each step individually.

Mistake 2: Postponing cleanup until after migration

Outdated and erroneous data don't improve through import. They just become harder to identify because they're now in a new context. Clean up before migration.

Mistake 3: Only training the ISM

If only the ISM knows the new tool, the same single-point-of-failure risk as with Excel emerges. Train all people who work with the tool and document the key workflows in a brief guide.

Mistake 4: Not planning for parallel operation

Without parallel operation, there's no safety net. If data loss is discovered after the import, restoration from the Excel files is time-consuming and error-prone.

Mistake 5: Replicating the old process one-to-one

Migration is an opportunity to improve processes. If you had a cumbersome controls tracking workflow in Excel, don't replicate the cumbersome process in the tool — use the tool's features to simplify the process. Ask yourself at each process step: are we doing this because it's sensible, or because Excel didn't allow anything else?

Timeline: Realistic planning for the migration

For an ISMS with roughly 150 assets, 80 risks, and 60 controls, you can expect the following timeframe:

Weeks 1-2: Inventory and cleanup. Identify all sources, check data quality, clean up. Effort: approx. 3-4 person-days.

Week 3: Field mapping and test preparation. Create mapping, prepare test data, conduct test import with a small dataset. Effort: approx. 2 person-days.

Weeks 4-5: Import in stages. Assets, risks, controls, SoA, documents. Each with verification. Effort: approx. 4-5 person-days.

Weeks 6-9: Parallel operation. New data only in the tool, training, report testing. Effort: approx. 1 person-day per week for comparison and support.

Week 10: Shutdown and archiving. Final check, archiving, communication. Effort: approx. 1 person-day.

Total effort: roughly 15-18 person-days spread over 10 weeks. That's manageable, but presumes the data quality in Excel is not catastrophic. For a heavily grown ISMS with inconsistent data, missing fields, and many duplicates, the cleanup phase can take significantly longer.

After migration: What changes

The switch from Excel to an ISMS tool is more than a tool change. It changes the way you work with your ISMS. Incidentally: if you're migrating not from Excel but from an existing cloud solution, partially different rules apply, which are described in the guide to migrating from cloud to self-hosted.

Links become visible. In the tool, you can see at a glance which risks relate to an asset, which controls address a risk, and the implementation status. In Excel, you had to jump between worksheets and search manually.

Tracking becomes automatic. Open controls, overdue deadlines, and unassessed risks appear in dashboards and notifications. You no longer have to actively look for them.

Collaboration becomes possible. Multiple people can work in the tool simultaneously without locking each other out of files or overwriting changes.

Audit-readiness increases. Change history, timestamps, and user attribution are automatically documented. During an audit, you can demonstrate who made which assessment when.

The ISM is relieved. Instead of serving as the central bottleneck maintaining all data, the ISM can delegate tasks and focus on steering and improving the ISMS. ISMS Lite offers a structured import process that simplifies the field mapping between Excel columns and tool fields and significantly reduces migration time.

The most important advice in closing: don't treat the migration as a purely technical project. It's a change management project where you need to bring along people who are accustomed to Excel. Explain the why, offer training, and be patient. The transition takes time, but it's worth it.

Further reading

• Choosing ISMS software: Criteria, comparison, and decision guide
• Self-hosted vs. cloud: Compliance aspects of ISMS tools
• ISMS in 6 months: A realistic experience report
• IT asset management in the ISMS: From inventory to protection needs assessment
• ISMS documentation overview: What you really need