Turning a Stalled XML Migration into Steady Progress

After a contract engagement with a standards organization, I was asked to help with a troubled XML migration.

The organization uses XML as a source format for codes, standards, and rules across industries such as construction and electrical work. Those documents are later rendered into different forms, including web and PDF publications.

It was moving hundreds of documents from one XML schema to another. By the time I joined, the new schema had already been designed and much of the conversion work had been outsourced.

The migration was not progressing reliably.

When progress becomes rework

The target schema still had limitations and the existing XML was messy and inconsistent. Vendors would deliver converted documents, the organization would review them, and issues would go back and forth between the teams.

Some problems were found late. A change intended to fix one document or presentation issue could create regressions elsewhere, especially where the XML schema and the CSS used for Prince PDF rendering were tightly coupled.

The process often stalled completely. Effort went into reviewing and correcting documents, but fixes could create new problems that would only appear later.

The most obvious missing capability was automatic validation.

People are not validation machinery

Some of the documents were more than a hundred pages long, and every character and structural relationship could matter. Asking people to inspect the same documents repeatedly was expensive, slow, and inherently unreliable.

People are useful for judgment and exceptions. They are not well suited to repeatedly checking large volumes of deterministic rules by hand.

I designed and built a validation process that combined several tools and checks into one repeatable workflow. It checked structural and schema rules, content consistency, references and relationships, known conversion issues, and other conditions that could be expressed reliably. Rendering through Prince was included as one downstream check, but most validation happened before the document reached PDF generation.

At the time, complete automation was not realistic. The source data and schema were too inconsistent, and the AI tools available then were not yet strong enough to handle the remaining ambiguity reliably. The goal was simple: catch as many issues as possible before manual review, reduce follow-up rounds, and keep documents moving smoothly through the pipeline. Human reviewers could focus on the cases that actually required judgment instead of repeatedly checking the same predictable conditions.

One shared quality check

The workflow became straightforward:

1. Vendors converted and prepared the documents.
2. They ran the validation tool.
3. The output showed what needed attention.
4. Vendors corrected the issues and ran it again.
5. The organization could run the same validation independently before accepting the work.

This gave the vendors and the organization a shared, repeatable definition of many basic quality conditions. The shared checks reduced reliance on a manual review loop, allowing both sides to focus their attention on the remaining exceptions.

As new issues appeared, we extended the validation rules, so the process grew stronger with each iteration.

The effect was substantial. Costly manual validation was reduced significantly, vendor output became cleaner before the organization’s review, and the migration could make more dependable progress.

The limits of a late intervention

I also explored whether most of the conversion could be automated, with manual involvement reserved for the genuinely ambiguous cases. A rough target of 90–95 percent automation seemed plausible, with the remaining work requiring human judgment or decisions about the underlying content.

That approach showed promise, but I joined after important architectural and budget decisions had already been made. I could improve the pipeline and build safeguards around it, but I did not have the authority to revisit every premise of the project.

That is a common constraint in real technical work. The better technical direction is not always the direction an organization is prepared to choose once money has been spent, vendors are engaged, and existing responsibilities have formed around the current approach.

The organization later hired a full-time employee to carry the work forward internally, and I trained her on the validation tools and the broader migration context. Once she was up to speed, the work transitioned to her.

What Experience Made Possible

The most valuable part of this kind of work is not familiarity with one XML standard or validation tool. It is being able to enter an unfamiliar system, understand how its technical and organizational parts interact, find the highest-leverage improvements, and carry them through within the authority and constraints available.

In this case, I was brought in as a problem fixer. I saw that the immediate issues were symptoms of a larger pipeline problem, built the validation capability the existing process lacked, and helped create a path for the migration to move forward. I could not redesign everything, but I could make the part I owned substantially better and leave the organization with a capability it could continue using.