Legacy Resurrection Studio – Project Story

What it does

Legacy Resurrection Studio is a three-chamber "necromancer's lab" for modernizing haunted legacy systems.

It helps engineers go from old PHP/jQuery/SOAP/Bootstrap systems to modern REST APIs and React UIs in minutes instead of weeks.

The Three Chambers

🔬 Legacy Reanimator

Analyzes legacy code (e.g. PHP + jQuery) and:

  • Detects risky patterns (SQL injection, XSS, deprecated APIs, global state, etc.)
  • Scores modernization risk
  • Suggests which modernization chamber to use next
  • Generates a downloadable migration report

⚡ API Necromancer

Takes SOAP/WSDL services and:

  • Extracts operations and types from WSDL
  • Maps them to REST endpoints
  • Generates an OpenAPI 3.0 spec with schemas, responses, and examples

👻 Ghost UI Converter

Takes legacy Bootstrap + jQuery HTML and:

  • Strips out jQuery, inline scripts, and Bootstrap classes
  • Generates React + TypeScript + Tailwind components
  • Uses a dark, spooky Kiroween theme with neon glows and ghostly icons

Together, these chambers form a mini migration pipeline:

Legacy code in → analysis → REST APIs + modern UI + migration plan out.


How we built it

Tech Stack

The project is built with:

  • Next.js 14 + TypeScript (App Router)
  • Tailwind CSS with a custom "necromancer" dark theme
  • lucide-react for spooky-but-clean icons

Architecture

A modular architecture under:

  • src/lib/analysis – code scanning, risk scoring, routing
  • src/lib/soap – WSDL parsing, SOAP → REST transformation, OpenAPI generation
  • src/lib/ui – HTML parsing, jQuery/Bootstrap detection, React generation

Kiro as an Engineering Partner

Instead of just "asking Kiro for code", I used Kiro with:

Specs (/.kiro/specs)

  • analysis-spec.yaml – legacy patterns + risk scoring rules
  • soap-spec.yaml – WSDL parsing + REST mapping + OpenAPI rules
  • ui-spec.yaml – Bootstrap → Tailwind mapping + jQuery → React hooks
  • theme-spec.yaml – dark spooky palette + spacing + typography
  • migration-plan-spec.yaml – phased migration strategies

Steering Docs (/.kiro/steering)

  • code-conventions.md – TypeScript & structure guidelines
  • migration-voice.md – how reports and recommendations should sound
  • ui-consistency.md – how every card/button/panel should look and feel

Hooks (/.kiro/hooks)

  • doc-sync.yaml – keep docs aligned with code
  • test-gen.yaml – generate test scaffolds for new logic

The Workflow

  1. Define behavior and constraints in specs
  2. Use Kiro to generate detectors, transformers, and UI components
  3. Refine with vibe coding sessions until everything compiled under TypeScript strict mode
  4. Wire up the three chambers as separate pages with a shared spooky UI

This let me build something that feels closer to an internal AWS migration tool than a quick weekend demo.


Challenges we ran into

1. Messy WSDL & SOAP edge cases

Realistic WSDLs can be deeply nested and inconsistent.

I had to iterate with Kiro multiple times to:

  • Recursively resolve complex types
  • Keep schemas readable
  • Still output valid OpenAPI 3.0

2. Converting "dirty" HTML + jQuery → clean React

The Ghost UI Converter needed to:

  • Remove <script>, onclick="", $('#id').val() and friends
  • Map layout classes like col-md-6 → Tailwind flex/grid
  • Preserve intent while changing structure

The hardest part was making sure the output was always valid JSX and matched the theme.

3. Consistency across 3 chambers

With three different tools in one app, it's very easy for the UI to feel stitched-together.

The ui-consistency.md steering doc became critical to:

  • Keep headings, shadows, colors, and spacing identical
  • Make the whole experience feel like one studio, not three separate tools

4. TypeScript strict mode everywhere

Running with strict mode forced me (and Kiro) to be disciplined:

  • No implicit any
  • Clear types for analysis results, routes, schemas
  • Safer refactors as the chambers evolved

Accomplishments that we're proud of

✅ Building three fully working migration chambers in one polished app:

  • Code analysis + reporting
  • SOAP → REST + OpenAPI
  • Legacy UI → React + Tailwind

✅ Using Kiro beyond simple prompting:

  • Specs, steering docs, and hooks living in /.kiro
  • Reproducible workflows, not just "magic outputs"

✅ Producing real artifacts developers can export and use:

  • Migration reports
  • OpenAPI 3.0 JSON
  • React components that drop into a Next.js app

✅ Delivering a UX that is:

  • Dark, spooky, and on-theme for Kiroween 🎃
  • Still clean, accessible, and readable

✅ Going from bare repo → working studio in roughly two focused days with Kiro as an accelerator


What we learned

1. Specs + steering > ad-hoc prompts

The moment I started treating Kiro like a teammate that needs a spec and coding standards, the quality of the output jumped dramatically.

2. AI shines at structured transformation tasks

Pattern detection, mapping SOAP → REST, Bootstrap → Tailwind – these are all highly structured tasks that are perfect for AI-assisted tooling.

3. Consistency doesn't have to be painful

Instead of manually tweaking every button and card, I locked the system design into a steering doc and let Kiro enforce it.

4. Small UX details matter for trust

Copy buttons, skeleton loaders, empty states, safe error messages – they don't add many lines of code, but they make the app feel like a tool you'd actually use at work.


What's next for Legacy Resurrection Studio

Short term:

  • Add a database migration chamber for schema analysis and modernization
  • Expand Ghost UI Converter to support more legacy frameworks (AngularJS, Backbone, etc.)
  • Generate test scaffolds alongside migration plans to help teams validate changes quickly

Longer term:

  • Turn this into a SaaS or internal tool that teams can point at real repositories
  • Add collaboration features: shared projects, comments on reports, progress tracking
  • Build out a community pattern library for legacy smells and migration recipes

The Goal

For Legacy Resurrection Studio to become a serious starting point for teams facing the "we have a huge legacy system, where do we even begin?" problem—and to show how far you can go when you treat Kiro as part of the engineering team.


Built with 💀👻 for Kiroween 2025

Built With

Share this project:

Updates