Skip to main content
The Morph Platform keeps expanding the kinds of modernization projects it can take on. This page describes what is supported today so you can pick projects that will produce the best results, and know what to expect before you start.
This list reflects the current state of the platform. We are actively adding support for more languages, frameworks, and application types — check back regularly, and reach out to support@modelcode.ai if you have a use case you’d like to see covered.

At a Glance

The Morph Platform supports backend, full-stack, and architectural modernization projects, with capabilities expanding through ModelDaemon.

Project Shape

The Morph Platform supports both single-repo and multi-repo modernization projects.

One-to-One (1:1)

  • One source repository → one target repository
  • Can be in-place migration or full rewrite

Multi-Repo (Many-to-Many)

  • Multiple source repositories → multiple target repositories
  • Supports:
    • Monolith → microservices decomposition
    • Cross-repo transformations
    • Service extraction and restructuring

Transformation Types

The Morph Platform supports multiple categories of transformation depending on the scope of your system.

1. Backend Modernization (Core Capability)

Backend migration projects with the following attributes:
  • Many-to-many or one-to-one repository transformations
  • Language-to-language translation or framework upgrades
  • Target applications may be RESTful APIs, CLI tools, or service-oriented systems
  • Supports monolith → microservices transformations
  • macOS and POSIX-compatible Linux distributions
  • Windows 10/11 and Windows Server 2019+ (amd64 only — Windows on ARM is not supported)
Morph capabilities:
  • Detects dependencies and architecture across repositories
  • Generates and executes structured migration milestones
  • Assists in identifying missing metadata and configuration
  • Supports build, run, and test workflows within the target environment

2. Full-Stack Modernization

Projects that include both backend and frontend components:
  • Backend and frontend systems (e.g., PHP + Twig → Java/Spring + React)
  • Frontend framework migrations (e.g., Angular → React, Twig → React)
  • Multi-repo or mono-repo architectures supported
  • Requires lifecycle configuration for frontend build and test processes
Morph capabilities:
  • Understands cross-layer dependencies between backend services and UI layers
  • Generates frontend transformations aligned with backend changes
  • Supports validation through build and test workflows where available
  • Assists with configuration of frontend tooling and environments

3. Architecture & Refactoring Transformations

Projects focused on improving system structure and maintainability:
  • Monolith → microservices decomposition
  • Service extraction, consolidation, or restructuring
  • Codebase refactoring without full language migration
  • Dependency standardization and modernization
Morph capabilities:
  • Builds architectural understanding across repositories
  • Applies transformations incrementally through milestones
  • Maintains compatibility with existing system behavior
  • Enables iterative modernization without requiring full rewrites

Supported Languages

The Morph Platform supports modernization projects whose source and/or target is one of the following languages:

Python

Java

Go

C#

PHP

Ruby

Kotlin

Rust

Scala

C++

C

Groovy

Clojure

Ada

Node.js

TypeScript

JavaScript

HTML

CSS

Sass

SCSS

Less

For each of the above, all common frameworks and micro-frameworks (web, RPC, CLI, background worker, etc.) are in scope.

Application Shape

The target application can be:
  • A RESTful service (HTTP API, gRPC gateways, etc.)
  • A command-line (CLI) tool
  • A full-stack application (backend + frontend)
The Morph Platform validates migrations by executing build, test, and runtime workflows.
  • CLI and API-based validation are fully supported
  • UI-based validation is supported where build/test workflows are available

Environment & Execution Model

The Morph Platform operates directly within your application environment via ModelDaemon.
  • With ModelDaemon, execution environments are more portable and less dependent on fixed filesystem or container assumptions
  • Lifecycle discovery and guided setup assist in configuring build and runtime environments
  • In complex or highly customized systems, developer input may still be required
For best results:
  • The application should build and run in the target environment
  • Dependencies (services, APIs, packages) should be accessible
  • Testable workflows (CLI, API, or UI-based) should be available

What’s Not Fully Supported Yet

The Morph Platform is built for backend services, CLIs, and full-stack web apps. The following kinds of projects are not supported as modernization migrations today:
  • Native mobile applications — iOS, Android, and other mobile-first stacks (device SDKs, mobile UI frameworks, app-store packaging workflows)
  • Desktop GUI applications — thick-client or native desktop apps whose primary artifact is a desktop installable (as opposed to a service or web app you run locally)
  • Plugins and extensions — IDE plugins, browser extensions, editor extensions, and other code that runs inside a host application rather than as a standalone service or site
If your project mixes supported and unsupported surfaces (for example, a web API plus a mobile client), focus the migration on the supported components or contact support@modelcode.ai before committing. For any complex requirements, validate setup during project initialization.

Evaluation & Performance

Morph performance is continuously evaluated across single-repo and multi-repo modernization scenarios.
  • Supports both single-repo and multi-repo transformations
  • Designed to achieve high test pass rates and successful milestone completion
  • Outcomes vary depending on system complexity, dependency availability, and test coverage

Checking Whether Your Project Is Supported

The Morph Platform does not pre-screen your modernization goal, so use the guidance on this page to judge fit before you begin. If your project sits close to the boundary — or mixes supported and unsupported surfaces — contact support@modelcode.ai before committing. Once the project is created, the Project Spec is where scope becomes concrete. Changes are cheapest here — later course corrections mean editing milestones or adding ad hoc work. See Project Spec for the walkthrough.

Still Not Sure?

If you’re unsure whether your project qualifies, or you have a modernization in mind that doesn’t quite fit, reach out to support@modelcode.ai.