How AWS Transform Custom Melts Away Your Technical Debt Like Snow in the Sun

Technical Debt: A Daily Burden

Technical debt creeps up on you fast. As soon as you have more than one project to manage, you have to split your time and make choices. This is where technical debt begins. It can also arise from lack of time, or from choices that postpone seemingly less essential functions like documentation or testing. And every day it deepens with new updates and frameworks being released or no longer maintained.

In my case, I had several TypeScript projects in production on Gatsby + Contentlayer 2, deployed statically on Amazon S3 with CloudFront. The problem? Contentlayer 2 is no longer maintained, creating security vulnerabilities and blocking updates. Every passing day, technical debt accumulates.

We will see here how AI and more specifically AWS Transform Custom can help us melt this debt like snow in the sun, by migrating to Next.js 15 with all modern best practices.

AWS Transform Custom: The Magic Eraser for Technical Debt

What is AWS Transform Custom in a Nutshell?

AWS Transform Custom is a service launched in December 2025 that uses agentic AI to perform large-scale modernizations of software, code, libraries and frameworks. Unlike traditional refactoring tools, it handles diverse scenarios:

• Language version upgrades
• API and service migrations
• Framework upgrades and migrations
• Code refactoring
• Organization-specific transformations

The real magic: the agent continuously learns from each execution and developer feedback, delivering higher quality and reproducible transformations without requiring automation expertise.

The Concrete Advantages of AWS Transform Custom

1. Time Savings

Code modernization or transformation takes time, whether for implementation or testing. Although guides exist to accelerate certain migrations, they must be implemented with our coding standards and validated to ensure all cases are correctly handled.

Agentic AI can bring great value here. By drawing inspiration from other files in your project and the standards you share with your agents (steering documents), agents will produce code much faster than a developer.

2. Built-in Transformation Patterns

AWS Transform Custom supports 10 transformation patterns with different complexity levels:

My use case: Framework Migration (Gatsby→Next.js 15) - High Complexity

3. Continuous Learning

One of AWS Transform Custom's flagship features: the agent learns from each execution. The system automatically captures:

• Execution trajectories
• Developer feedback
• Code corrections
• Validation build results

This information is transformed into Knowledge Items (KI) that improve future transformations. The more you use it, the better it gets. You'll save time by not needing to reformulate your prompts to handle all cases.

Our Use Case: Five Projects to Transform to Next.js 15

Context: A Heterogeneous Portfolio in Distress

I had five unmaintained projects:

1. A demo with Gatsby for a previous article
2. A showcase website "bruas.fr"
3. My online CV cv.bruas.fr with multilingual support (the only site with this feature)
4. The previous version of this site sylvain.bruas.fr, which I had already transformed before AWS Transform Custom's release, and which allowed me to define the target
5. A static page serving as my virtual business card (pure HTML). This project is here to test the tool's limits in a very heterogeneous environment

Current stack:

• Framework: Gatsby (obsolete for my needs)
• Content: Contentlayer 2 (⚠️ unmaintained - security vulnerabilities)
• Articles: Markdown with frontmatter
• Deployment: Amazon S3 + CloudFront (static)
• IaC: Terraform

Target stack:

• Framework: Next.js 15 (latest version)
• Content: @next/mdx or content-collections (native alternatives)
• Architecture: App Router with Server Components
• Build: Turbopack (new ultra-fast bundler)
• Up to date with packages and CVEs
• Complete removal of Gatsby
• If we have a multilingual site, we create one project per language to facilitate SEO

The Contentlayer 2 problem: This project has been unmaintained since 2023, creating security vulnerabilities and preventing dependency updates. Next.js 15's native alternatives (@next/mdx, content-collections) are more performant and maintained.

Clone projects: Projects that started from the same sources but evolved with different modules (I18N), and not necessarily with best practices. Making them converge again toward a common platform requires significant effort.

Phase 1: Start with a Complete Audit

Before any transformation, I used Kiro (an AI assistant for developers) to perform a thorough audit of my projects.

I asked it to perform a complete audit of my projects using sub-agents to go faster:

Prompt used:

For each project, give me a security audit, best practices, test coverage, etc. Put the result in a <project name>.md file
Give me a global summary in the form of various tables in projects-data.md
Use sub-agents to go faster

Kiro automatically analyzed:

• Obsolete dependencies with npm audit
• Security vulnerabilities
• Existing test coverage
• Code quality with ESLint
• TypeScript best practices

📊 Global Summary Table

⚙️ Infrastructure Issues Table

Critical points identified:

• ⚠️ Contentlayer 2: Unpatched CVE vulnerabilities
• ⚠️ Gatsby: Version 4.x, while v5 is out (but complex migration)
• ⚠️ Node.js: Version 16 (EOL), need to migrate to 22 LTS

This audit phase is crucial. AWS Transform Custom works better when it understands the initial state of your codebase. Kiro helped me prepare this work by precisely documenting:

• Technical architecture
• Data flows
• Components
• Theme management
• Routing system
• SEO and metadata
• Infrastructure
• Performance
• Security

This is a first piece of technical debt resolved: generative AI enables creating a solid documentation base that only needs to be reviewed and adjusted.

Tip: Document everything you find. AWS Transform Custom will use this documentation as References to better understand your context.

Phase 2: Adding Tests with AI

AI in Service of Quality

Before launching the transformation, I used Kiro to generate missing tests. Why? Because AWS Transform Custom uses tests to validate its transformations via the Build and Validation Command.

The goal is to have meaningful coverage of about 80%, with unit, integration and end-to-end tests that provide value. We target edge cases and critical application features (SEO, image handling, build, mobile HTML rendering...).

Test Coverage: 80% Target

After this intensive test generation phase:

Phase 3: Pilot Project - Demo with AWS Transform Custom

Why Demo as Pilot?

I chose Demo because it was:

• Simple: Clear architecture with ~50 components
• Representative: Uses the same patterns as other projects (Gatsby, Contentlayer 2, TypeScript)
• Interesting but not vital: Allows experimenting without major business risk

AWS Transform Custom Installation and Configuration

Step 1: CLI Installation

# AWS Transform CLI installation (recommended method)
curl -fsSL https://desktop-release.transform.us-east-1.api.aws/install.sh | bash

# Verification
atx --version
# Output: Version 1.x.x

Prerequisites:

• Git installed and configured
• Node.js 18+ (for JavaScript/TypeScript projects)
• Internet connection with access to AWS Transform endpoints

Step 2: Configuration

# AWS authentication configuration
# Option 1: Via environment variables
export AWS_ACCESS_KEY_ID=your_access_key
export AWS_SECRET_ACCESS_KEY=your_secret_key
export AWS_REGION=**us-east-1**

# Option 2: Via AWS CLI (recommended)
aws configure

# Option 3: Via AWS profile
export AWS_PROFILE=your_profile_name

Required IAM permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "transform-custom:*"
      ],
      "Resource": "*"
    }
  ]
}

Step 3: Define the Transformation

AWS Transform Custom offers an interactive natural language mode to define the transformation. This is where the magic happens.

# Launch interactive mode
atx

# The agent starts in conversational mode


 █████╗ ██╗    ██╗███████╗                                                     
██╔══██╗██║    ██║██╔════╝                                                     
███████║██║ █╗ ██║███████╗                                                     
██╔══██║██║███╗██║╚════██║                                                     
██║  ██║╚███╔███╔╝███████║                                                     
╚═╝  ╚═╝ ╚══╝╚══╝ ╚══════╝                                                     
                                                                               
████████╗██████╗  █████╗ ███╗   ██╗███████╗███████╗ ██████╗ ██████╗ ███╗   ███╗
╚══██╔══╝██╔══██╗██╔══██╗████╗  ██║██╔════╝██╔════╝██╔═══██╗██╔══██╗████╗ ████║
   ██║   ██████╔╝███████║██╔██╗ ██║███████╗█████╗  ██║   ██║██████╔╝██╔████╔██║
   ██║   ██╔══██╗██╔══██║██║╚██╗██║╚════██║██╔══╝  ██║   ██║██╔══██╗██║╚██╔╝██║
   ██║   ██║  ██║██║  ██║██║ ╚████║███████║██║     ╚██████╔╝██║  ██║██║ ╚═╝ ██║
   ╚═╝   ╚═╝  ╚═╝╚═╝  ╚═╝╚═╝  ╚═══╝╚══════╝╚═╝      ╚═════╝ ╚═╝  ╚═╝╚═╝     ╚═╝

┌──────────────────────────────────────────────────────────────────────────────┐
│                              Region: us-east-1                               │
└──────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│                                Trusted Tools                                 │
│                                                                              │
│ Built-in Trusted Tools                                                       │
│   Configuration: Built-in read-only tools                                    │
│   • file_read                                                                │
│   • get_transformation_from_registry                                         │
│   • list_available_transformations_from_registry                             │
│   • document_manager (add operations only)                                   │
│   • editor (view and find_line operations only)                              │
> 

Conversation with the AI agent:

Me:

I want to migrate my Gatsby + Contentlayer 2 project to Next.js 15 with App Router and Server Components

AWS Transform:

I understand you want to migrate your project from Gatsby + Contentlayer 2 to Next.js 15 with App Router and Server Components.

Before creating a new transformation for this use case, let me check if there are already similar transformations in the registry that could be useful.

I see there are 8 AWS-managed transformations in the registry, but none specifically matches a Gatsby to Next.js 15 migration with App Router and Server Components.

I will create a new custom transformation for your use case: migration from Gatsby + Contentlayer 2 to Next.js 15 with App Router and Server Components. I will help you create a transformation definition to migrate your project from Gatsby + Contentlayer 2 to Next.js 15 with App Router and Server Components. This migration will allow you to benefit from the latest Next.js features, including improved server-side rendering, Server Components for better performance, and a more modern architecture.

To create an effective transformation definition, it would be helpful to know:

• What type of content do you manage with Contentlayer (blog, documentation, marketing)?
• Do you use specific data sources (Markdown, MDX, JSON)?
• Do you have particular Gatsby plugins or important custom features?

Me:

you should find all the information in the docs directory

AWS Transform:

I've created a comprehensive transformation definition to migrate your Gatsby + Contentlayer 2 project to Next.js 15 with App Router and Server Components.

The definition covers all aspects of the migration identified in your documentation, including:

• Migration from Gatsby architecture to Next.js 15 App Router
• Replacing Contentlayer 2 with native Next.js solutions for Markdown/MDX content
• Converting the theming system with Styled Components
• Migrating images from gatsby-plugin-image to next/image
• Transforming the routing and navigation system
• Adapting SEO with the new Next.js 15 Metadata API
• Migrating the test infrastructure (Jest, Cypress)
• Updating the AWS deployment pipeline

The definition is structured in 15 detailed steps and includes 20 validation criteria to ensure the migration is complete and functional. The transformation definition for migrating your Gatsby + Contentlayer 2 project to Next.js 15 with App Router and Server Components has been successfully created. It is now available in your session at:

~/.aws/atx/custom/XXXXXX/artifacts/tp-staging/transformation_definition.md

The transformation covers all key aspects of your migration:

• Architecture Gatsby → Next.js 15 App Router
• Replacing Contentlayer 2 with native Next.js solutions
• Converting the theming system with Styled Components
• Image migration (gatsby-plugin-image → next/image)
• Routing and navigation transformation
• SEO adaptation with the Next.js 15 Metadata API
• Test infrastructure migration
• AWS deployment pipeline update

What would you like to do next?

Me:

A few points are missing, tell me if you can handle all of them:

• Build: Turbopack (new ultra-fast bundler)
• IaC: Terraform (standardized with modules)
• Up to date with packages and CVEs
• If we have a multilingual site, we split it into 1 project per language to facilitate SEO

AWS Transform:

I will now modify the transformation definition to integrate all these elements. I understand you want to verify if I can integrate all these points into the transformation definition. Let me explain what I can handle:

Points I can integrate directly into the transformation definition:

✓ Build with Turbopack

✓ Package management and CVE verification

✓ Multilingual architecture (1 project per language)

Phase 4: Executing the Transformation on Demo to Validate the Plan

Me:

Apply this transformation to my code in the demo directory

AWS Transform:

I will apply this transformation to your code in the demo directory.

📋 Transformation Plan Summary

The plan includes 15 steps organized progressively and logically:

🏗️ Phase 1: Base Infrastructure (Steps 1-2)

🔄 Phase 2: Core Component Migration (Steps 3-6)

🎨 Phase 3: SEO, Styling and Tests (Steps 7-9)

🚀 Phase 4: Infrastructure and CI/CD (Steps 10-12)

🔒 Phase 5: Security, GDPR and Finalization (Steps 13-15)

📝 Important Note

I adapted the plan because your project does not use Contentlayer 2 as mentioned in the transformation definition, but directly gatsby-transformer-remark with Markdown files. The plan reflects this reality and proposes a migration to a native Next.js system with gray-matter and next-mdx-remote.

The plan is now available here: ~/.aws/atx/custom/2026XXXX/artifacts/plan.json

We can see that the tool is flexible enough to adapt to slight variations between my base model and the actual implementation.

Me:

Apply the plan

AWS Transform:

An execution agent will handle the implementation of this plan to transform your Gatsby application into Next.js 15.

[several minutes pass...]

Due to the substantial token usage and the complexity of remaining steps (Steps 5-15), I need to provide a summary of the completed work and document the remaining steps that would need to be completed:

Summary of Completed Work

Successfully Completed Steps (1-4):

✅ Step 1: Next.js 15 Project Structure initialized with TypeScript, App Router, and Turbopack

✅ Step 2: Content Management migrated from Gatsby GraphQL to file-based system with gray-matter and next-mdx-remote

✅ Step 3: All Gatsby pages converted to Next.js App Router with Server Components (home, about, 404, blog posts)

✅ Step 4: Styled Components theme system migrated with proper hydration registry and theme provider

Build Status: All 4 steps verified with successful builds ✓

I chose to stop there for the day, waiting a few hours to get a real cost estimate.

However, I tried to get the consumption, and on this point I was a bit disappointed.

AWS Transform:

Based on the token usage information I can see in the history, here is the token cost for the first completed steps:

Token usage by step:

• Initial startup: ~28,000 tokens (reading the plan, VCS setup)

• Step 1 (Initialize Next.js 15): ~16,000 tokens

• Step 2 (Migrate Content Management): ~12,000 tokens

• Step 3 (Convert Pages to App Router): ~18,000 tokens

• Step 4 (Migrate Styled Components): ~9,000 tokens

• Step 5 (start - Migrate Gatsby Components): ~18,000 tokens

Total used so far: ~119,675 tokens out of 200,000 available

The next day, I checked the cost explorer and found a consumption of about $6. This represents 174 min (~3 h) of agent time! The cost isn't very high, but I still wonder about this figure, as 3 hours of agent seems a bit excessive.

To put this in perspective, this definition and first plan test session cost me 30% of a monthly Kiro Pro subscription.

On the financial front, at this point in the study, I'm not really satisfied. Scaling the migration will need to make up for this initial impression of over-billing.

For this article, I asked to only do steps 5 and 6 to be able to launch the project with Next.js, without doing all transformations to save time.

I waited a few more minutes and Transform handed back control.

AWS Transform:

Steps 5 and 6 are completed successfully.

I launched the site and it started without issues.

AWS Transform Custom automatically performed:

1. Step 1: Next.js 15 with TypeScript and App Router
2. Step 2: Content migration (Gatsby GraphQL → Markdown files)
3. Step 3: Gatsby Pages → App Router with Server Components
4. Step 4: Styled Components + Theme System
5. Step 5: Gatsby Link/Image → Next.js Link/Image
6. Step 6: Interactive Client Components (NavBar, PostGrid, CategoryFilter)
7. Step 8: Font optimization with next/font
8. Step 14: Gatsby dependency cleanup
9. Step 15: Final validation

I set non-essential steps as optional. The site displays, properly uses Next.js, but I can see my initial prompt isn't perfect: image handling referenced in Markdown files for example isn't correct. This point will need rework.

Generated Transformation Report

AWS Transform Custom automatically generates a detailed report:

📊 TRANSFORMATION STATUS

✅ BUILD STATUS: **SUCCESS**
- ✓ `yarn build`: Compilation successful
- ✓ 10 static pages generated
- ✓ Static export completed
- ✓ No build errors

🎯 COMPLETED STEPS

6 major steps completed successfully:

1. **Step 1** - Initialize Next.js 15 ✅
   - Next.js 15.5.12 + React 18.3.1
   - App Router + TypeScript
   - Turbopack configured

2. **Step 2** - Content Management ✅
   - Migration Gatsby GraphQL → Next.js native
   - gray-matter + next-mdx-remote
   - lib/posts.ts + lib/metadata.ts created

3. **Step 3** - Pages Gatsby → App Router ✅
   - Server Components
   - Dynamic routes `/blog/[slug]`
   - generateStaticParams() implemented

4. **Step 4** - Styled Components ✅
   - Theme system migrated
   - Registry for hydration
   - Dark/Light mode functional

5. **Step 5-6** - Components + Interactivity ✅
   - gatsby Link → next/link
   - GatsbyImage → next/image
   - Client Components ('use client')

6. **Step 8-15** - Finalization ✅
   - Font optimization (next/font)
   - Gatsby cleanup complete
   - Final validation

📦 GENERATED PAGES


Route (app)                     Size     First Load JS
┌ ○ /                         10.4 kB    127 kB
├ ○ /about                      140 B    102 kB
├ ○ /info                      3.93 kB   117 kB
├ ● /blog/[slug]                140 B    102 kB
│   └ /blog/welcome-nextjs
├ ○ /feed.xml                   140 B    102 kB
├ ○ /robots.txt                 140 B    102 kB
└ ○ /sitemap.xml                140 B    102 kB


🚀 COMMITS MADE

4df Step 8-15: Font + Cleanup + Validation ✅
5e3 Step 5-6: Components Migration ✅
1ca Step 4: Styled Components ✅
f5e Step 3: App Router Pages ✅
f50 Step 2: Content Management ✅
885 Step 1: Next.js 15 Init ✅

🔍 RESULT

✅ NO ERRORS DETECTED

The transformation is complete and functional:
- Build: **SUCCESS**
- All pages: **Generated**
- Migration: **Completed**
- Commits: **6 commits made**

✅ The project is ready for development!
- Command: `yarn dev`
- URL: http://localhost:3000

It's a bit optimistic with the phrase "The transformation is complete and functional", but given the precision of my prompts and the work done, we can give it an 8/10.

Saving the Transformation

Let's now save the transformation:

> atx custom def publish  --sd ~/.aws/atx/custom/2026XXXX_XXXXXX_90eXXXX8/artifacts/tp-staging --description "Gatsby to Next.js 15 Migration" -n "gastby-to-nextjs"

👤 User Transformations:

┌───────────────────────────┬────────────────────────────────────────┬──────────────────┐
│ Transformation Name       │ Description                            │ Version          │
├───────────────────────────┼────────────────────────────────────────┼──────────────────┤
│ gastby-to-nextjs          │ Gatsby to Next.js 15 Migration         │ 3flmwvbjk81pu    │
│                           │                                        │ 3vo4rdh          │
└───────────────────────────┴────────────────────────────────────────┴──────────────────┘
                                                                                                  

Transformation at Scale and Putting the Tool to the Test

Now that the transformation is validated and published, I can use it on the other projects.

An Unrelated Site: Vcard-pro

Let's start with this project that is not a Gatsby project.

> atx custom def exec -n gastby-to-nextjs  -p vcard-pro    

┌──────────────────────────────────────────────────────────────────────────────┐
│                              Region: us-east-1                               │
└──────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│  🟡 You are using a user-created transformation which has not been reviewed  │
│                                   by AWS.                                    │
└──────────────────────────────────────────────────────────────────────────────┘

Do you have any additional preferences I should take into consideration beyond what is described in the Transformation Definition (e.g., specific version requirements, build or validation commands, infrastructure preferences, deployment targets, or any constraints I should be aware of)?

Please share any specific requirements or guidance you have, or let me know if I should proceed with the plan based on the transformation definition provided.

I don't provide additional info to see what it's capable of doing.

⚠️ Transformation Applicability Assessment

After analyzing the codebase at `vcard-pro`, I've determined that **this transformation definition does not apply to this codebase**.

Transformation Definition Requirements (Entry Criteria):
- Gatsby 5.x with React 18.x and TypeScript
- Contentlayer 2 for content management with Markdown/MDX files
- gatsby-plugin-image for image optimization
- Styled Components with theme system
- GraphQL queries for content fetching

Actual Codebase Analysis:
- Technology Stack: Static HTML/CSS + vanilla JavaScript
- Framework: None (no Gatsby, no React, no Next.js)
- Backend: Node.js script using `vcards-js` and `qrcode` libraries
- Purpose: vCard generator with static HTML display page
- Architecture: Simple static site with Node.js build script

**The codebase is a vanilla JavaScript vCard generator, not a Gatsby + Contentlayer application.**

Next Steps - Your Decision Required:

Would you like to:

1. **Abort the transformation** (Recommended) - This transformation definition is designed for Gatsby→Next.js migration and doesn't apply to this static HTML/JavaScript project.

2. **Proceed anyway** (Not recommended) - I could attempt to create a plan, but it would involve completely rewriting the application rather than migrating it, which is outside the scope of this transformation definition.

Please provide your preference: **Abort** or **Proceed anyway**?

Excellent response from the tool — it doesn't try to force-apply at all costs. This is a good safeguard, meaning I can let people with only partial knowledge of the application use AWS Transform Custom.

A Real Site to Migrate: bruas.fr

This is a very simple Gatsby site, let's see the result.

> atx custom def exec -n gastby-to-nextjs  -p bruas.fr 

Transformation Plan Created Successfully

I've analyzed the bruas.fr codebase and created a detailed 13-step transformation plan to migrate from Gatsby 5 + Contentlayer 2 to Next.js 15 with App Router and Server Components.

📋 Plan Overview

The transformation plan addresses:

Current State Analysis:
  ✅ Gatsby 5.12+ with React 18.2 and TypeScript
  ✅ Markdown content in `src/posts/blog/` with frontmatter
  ✅ Styled Components with Context API theme system
  ✅ Comprehensive test suite (Jest + Cypress)
  ✅ Existing Terraform infrastructure (S3 + CloudFront)
  ✅ GraphQL data layer for content queries

Migration Strategy:

1. **Initialize Next.js 15** - Set up project structure, App Router, Turbopack, TypeScript
2. **Migrate Content Management** - Replace GraphQL with native MDX/Markdown processing
3. **Configure Styled Components** - Set up registry for App Router SSR compatibility
4. **Convert Home Page** - Implement Server Components with PostGrid
5. **Migrate Navigation** - Convert NavBar to Next.js Link with client interactivity
[...]
7. **Blog Post Template** - Create dynamic routes with MDX rendering
[...]
13. **Finalize Migration** - Remove Gatsby, optimize, update documentation

For the exercise, I'll only take steps 1-7 and 13. I therefore ask the planning agent (with whom I'm exchanging) to modify the migration plan. We thus have total flexibility for the transformation if we stay in interactive mode. Once we've gained enough confidence, we can skip these steps and launch migrations in parallel.

Final Status

🎉 All issues have been successfully resolved!

The application now:
  ✅ Builds without errors
  ✅ Has properly configured Jest test environment  
  ✅ Uses Next.js-compatible mocks and configuration
  ✅ Generates 15 static pages successfully
  ✅ Maintains code quality and test integrity

There are still a few display details to fix, but the critical points are in place. The site is functional and passes the essential tests we set up beforehand.

Benefit of the operation: 100% time saved. The migration happened during one of my meetings — I only validated tool usage during that meeting, so zero distraction.

A Site Similar to the Target: cv

For this project, we'll simply verify the planning part to see if the multilingual site specificity is properly handled without help.

> atx custom def exec -n gastby-to-nextjs  -p cv  

Analysis Summary

After thorough analysis of the codebase at `cv`, I've identified the following:

Current State:
- Framework: Gatsby 5.13.7 with React 18.2.0
- Project Type: Digital CV/Resume website (NOT a blog)
- Content Management: GraphQL with JSON files (NOT Contentlayer 2)
- Styling: Styled Components 5.3.11
- i18n: gatsby-plugin-react-i18next with French (FR) and English (US) support
- Data Sources: Multiple JSON files in `data/` directory for jobs, skills, education, certifications, hobbies, etc.
- Features: Multilingual, responsive, PWA, dark mode, Google Analytics, SEO optimized

Entry Criteria Evaluation:

The transformation definition specifies migration from "Gatsby + Contentlayer 2 to Next.js 15" for a **blog application**. However, this codebase:

❌ Does NOT use Contentlayer 2 - Uses native Gatsby GraphQL with gatsby-transformer-json  
❌ Is NOT a blog - It's a CV/resume website without blog posts, categories, or typical blog features  
❌ No Markdown/MDX content - Uses structured JSON data files  
❌ No blog-specific features - No category filtering, infinite scroll for posts, or blog templates  

Recommendation:

This transformation definition does NOT match the codebase. The transformation is designed for a Gatsby blog using Contentlayer 2, but this is a Gatsby CV site using JSON data with GraphQL.

Despite a very similar structure, AWS Transform Custom doesn't fall into the trap and advises us not to continue, which was the expected answer.

We can also see that it properly detected the multilingual aspect of the site, which highlights the consideration of the multilingual rule in the transformation definition.

Conclusion: A Magic Eraser for Technical Debt

Kiro and AWS Transform Custom: A Winning Duo

Kiro considerably helped us prepare the work for AWS Transform Custom:

• In-depth technical debt audit
• Test generation (80%+ coverage)
• Documentation of existing patterns
• Identification of friction points

AWS Transform Custom then took over to:

• Define the migration plan
• Test this plan on a first project
• Automatically transform remaining projects
• Learn and improve with each transformation

You could do everything with your own prompts and scripts, but AWS Transform Custom gives us a framework and a shared library. This is the added value of this solution, which allows tracking, standardizing and auditing migrations.

The Final Verdict

If a large portion of your applications are on the same technology platforms, this tool will be a magic eraser to wipe away your technical debt.

In just a few hours you can modernize a project, focusing on needs rather than code to achieve this result. An expert's careful eye will always be needed at the end of the migration to verify performance and result quality. They will thus bring the greatest added value to the project.

We've seen that AWS Transform Custom doesn't just blindly apply plans. It correctly identifies projects and is capable of proposing the best trajectory for each one. We can therefore make this tool available to level 1 technical teams, who don't necessarily have the full context of each tool. With AI to assist them, they can apply transformations without falling into the most common traps, and consult an expert if the tool alerts them about the transformation's relevance to the project.

Recommendations to Get Started

1. Audit first
2. Test massively: Aim for 80% minimum coverage
3. Start small: Choose a simple and representative pilot project
4. Document: Provide references (docs, examples) to AWS Transform
5. Iterate: Approve knowledge items to improve subsequent transformations