5 Days to Migrate it ALL

The problem everyone knows

Most companies map their IT landscape in Excel. The file starts small, with one clean tab, then gradually grows. Three tabs become fifteen, then forty. Application names vary depending on who fills in the data, and columns multiply with no shared logic. After six months, one person in the organization still understands the file's structure. When that person is unavailable, the information becomes hard to access.

Visio and Draw.io diagrams create a different but equally concrete problem. A technical architecture diagram is accurate the day it gets created. Two weeks later, an application has changed versions, a data flow has been rerouted, a service has been decommissioned. The diagram stays the same. Its update gets postponed because it takes time, because it is tedious, because it will be "done before the next audit."

The outcome is predictable. When the executive committee asks for a view of the application landscape, it takes two days to assemble a PowerPoint from contradictory sources. When the security team asks for a list of inbound flows on a given perimeter, someone has to dig through three files and cross-check manually. The mapping exists, but it no longer serves its purpose.

This observation is neither new nor rare. It is the reality of most IT departments that have not yet moved to a dedicated tool. And the reason they have not moved is often the same: the fear that migration will take months.

In practice, it does not. With a structured method, five days are enough to get a first usable version in Boldo.

Days 1 and 2: scoping and cleanup

Defining the Metamodel in Boldo

The natural temptation, when opening an Enterprise Architecture tool for the first time, is to model everything at once: applications, servers, databases, business processes, capabilities, risks, projects. This is a common mistake. A metamodel that is too broad at launch slows down the migration and creates confusion.

The approach that produces the best results starts with three objects: applications, data flows, and business processes. Applications form the core of the inventory. Flows show who sends what to whom. Processes create the link between the technical layer and the business. These three objects cover the questions that stakeholders ask most frequently.

Boldo offers metamodel templates designed for this type of quick start, covering roughly 80% of common use cases. Additional layers (infrastructure, data, business capabilities) can be added in later iterations, once the foundation is stable and the teams have gotten comfortable with the tool.

The big Excel cleanup

This is the most decisive step of the sprint. Migration quality depends directly on source data quality. A clean import into Boldo from a poorly structured file will only produce a poorly structured repository.

1. The first task is naming. "SAP ECC", "SAP", "SAP ERP 6.0", and "the accounting SAP" all refer to the same application. It is best to choose one canonical name and stick with it. A simple alphabetical sort on the "Name" column reveals most duplicates in a few minutes.
2. The second task is filling in missing fields. Each application benefits from having, at minimum, a standardized name, a business owner (even an approximate one at this stage), and a lifecycle status: in production, under construction, or being decommissioned.
3. The third task is removing noise. Tabs labeled "Archive", "Copy of Copy (2)", "Test JM" add nothing to the target repository and can be deleted without loss.

This cleanup work takes between four and eight hours depending on file size and condition. It is a worthwhile investment: each hour spent at this stage saves roughly three hours after import, in reconciliation and correction.

Days 3 and 4: import and conversion techniques

Express import of inventories

Boldo has an import feature with automatic mapping. The principle is straightforward: upload the cleaned Excel file, and Boldo detects the columns and proposes a mapping to the metamodel properties configured on days 1 and 2. All that remains is to review or adjust the mapping, then launch the import.

The automatic mapping recognizes common column headers (name, description, status, owner, go-live date). For an inventory of 200 to 500 applications, the operation takes a few minutes.

A practical note: it is more effective to import applications first, then flows in a second pass. Boldo creates links automatically when source and target application names match objects already present in the repository.

The Visio and Draw.io problem

This is the most frequent friction point in a migration. Teams often have dozens of diagrams representing flows, technical architectures, or application landscapes. The natural reflex would be to import them as images attached to objects. This would be a mistake, because an image creates exactly the same problem as before: static, not maintainable, disconnected from the repository.

The value of a Visio or Draw.io diagram does not lie in its shapes and colors, but in the objects and relationships it represents. Each box corresponds to an application. Each arrow corresponds to a flow. The goal is to turn these visual elements into connected objects in Boldo.

The AI accelerator

Draw.io files (.drawio) and Visio files (.vsdx) are not simple images. They are structured files. A .drawio file contains XML describing every shape, every connector, and every label. A .vsdx file is a ZIP archive containing several internal XML files. This structure is readable by an LLM.

The method breaks down into three phases.

The first phase consists of extracting the source XML. For Draw.io, the .drawio file is already raw XML. For Visio, it is enough to decompress the .vsdx and retrieve the internal XML files.

The second phase consists of submitting this XML to an LLM (ChatGPT, Claude, or another). The prompt asks the model to extract the list of all elements (nodes) with their labels, and the list of all connections (edges) with their source and target. The expected output format is a CSV with two tables: one for objects, one for relationships.

The third phase consists of importing the generated CSV into Boldo through the standard import feature.

The time savings are considerable. Across a set of 20 to 30 diagrams, this technique saves dozens of hours of manual re-entry. Relationships and data flows are extracted automatically from the XML code, and the import file is directly compatible with Boldo.

A note on the product roadmap: a native Draw.io and Visio conversion function is planned in Boldo, without relying on an external LLM. Looking further ahead, by the end of 2026, the ambition is to go further with a function capable of transforming any file (image, interview notes, text document) into a structured model directly usable in Boldo.

Consolidation

At this point, Boldo contains two data sources: objects imported from Excel (the inventory) and objects extracted from diagrams (flows and relationships). These two sources need to be reconciled.

Boldo detects potential duplicates through name matching. If "SAP ECC" already exists from the Excel import, the object extracted from a Draw.io diagram will be proposed as a merge rather than a new creation. Flows extracted from diagrams enrich the existing application records. The flat inventory becomes a connected graph.

This reconciliation phase also has a valuable side benefit: it surfaces inconsistencies. Flows pointing to applications missing from the inventory, applications appearing in no diagram, dependencies that nobody had formalized. It is a data cleanup exercise as much as a technical one.

Day 5 and beyond: governance and value

Assigning owners

A mapping without identified owners degrades within a few months. By the fifth day, every critical application benefits from having a business owner assigned. In Boldo, this is a native property on every object.

A review cadence is also worth defining. Quarterly reviews for critical applications and semi-annual reviews for the rest cover most needs. Boldo can send automatic reminders to owners so they confirm that the information is still accurate.

Governance rules do not need to be complex at the start. Two questions make a good starting point: who can create a new object in the repository, and who validates a decommission.

Adjusting graphical views

Boldo generates views automatically from the repository. These default views are a good starting point, but they benefit from being customized for different audiences.

An "application landscape" view organized by business domain meets executive committee expectations. A "data flow" view focused on critical processes meets the needs of security and compliance teams. Colors and layout benefit from making the view understandable without verbal explanation. If every box in the diagram requires a walkthrough, the view can probably be simplified.

Showing rather than telling

The return on investment of a Boldo migration becomes concrete at the first post-migration architecture committee meeting.

Instead of projecting an Excel table, the architect opens Boldo and browses live. One click on an application displays its dependencies, its flows, and its owner. The question "which applications are impacted if this middleware is shut down?" gets an answer in seconds, where it previously took two days of searching through a spreadsheet.

Boldo views are shareable by link. Stakeholders can explore the architecture on their own, at the right level of detail, without waiting for an architect to prepare a dedicated export.

Starting the sprint

The method is documented and the timeline is realistic. Boldo's Self-Service mode allows teams to start without waiting for a consulting session.

Start a free trial on Boldo and kick off the sprint this week.

The Customer Success team also offers guided onboarding sessions to support the first two days. Just reach out.