15,000 Flash Widgets to HTML5

Problem

A large library of interactive learning widgets had to move from Flash to browser-native HTML5. Rebuilding each widget as a one-off would not scale; the migration needed a reusable rendering engine, a predictable production workflow, and quality checks that could keep pace with delivery.

Constraints

• 15,000 interactive widgets had to move through the workflow.
• Existing behavior was reproduced through a proprietary rendering engine.
• Vendor contributors needed training and a consistent development process.
• Quality checks had to scale with migration throughput.

Approach

• Analyzed requirements and estimation inputs before scaling production.
• Refactored the rendering engine around repeatable widget behavior.
• Trained vendor teams and optimized the migration workflow.
• Built quality checks into the delivery process rather than relying on end-stage inspection.

Architecture decisions

• Kept reusable behavior in the shared renderer so fixes could apply across widget types.
• Separated engine work, migration production, and verification into explicit stages.
• Made quality checks a workflow gate instead of an informal handoff.

Trade-offs

• A shared engine increased migration leverage but concentrated compatibility risk in one layer.
• Parallel vendor throughput required stricter conventions, training, and review.

Impact

• Supported conversion of 15,000 widgets within the documented November 2014 to May 2015 project window.
• Created a repeatable workflow for distributing and reviewing migration work.
• Made quality part of the production system rather than a final manual phase.

What I learned

• At this scale, legacy migration is a systems problem, not a sequence of file conversions.
• The rendering engine, migration workforce, and QA workflow have to be designed together.