How engagements work

How a vFunction engagement works

A vFunction engagement is a modernization project on a large Java or .NET application. It's run by vFunction's forward-deployed engineers with your team, inside your environment, using the vFunction platform and your AI coding tools.

We work until your team can run the process alone. Our experienced team drives successful outcomes, and you will not be left to do it alone.

Why an engineer comes with the platform

Software to design your solution. Experienced engineers to get you through it.

The first analysis of a large application will show your team the workings of your application as it has never been seen. The changes still have to be made, one domain at a time, inside a live production system. We don’t let a diagnosis stall the momentum on your project.

We equip your teams with an experienced modernization engineer who, working inside your environment, guides and helps deliver the successful modernization.

So the platform comes with the engineer.

How vFunction is priced and funded →

Step by step

What happens in an engagement

Six steps, in the order they usually happen. The order bends to the application.

Choose the application

1

The large Java or .NET application that has to change but attempts are failing, usually past 500,000 lines of code or 1,000 classes. Your team provides access to the running application, its environment, and the people who know the domain.

Observe it running

2

vFunction’s lightweight agent tracks the application’s behavior in production or QA. The engineer and your domain experts shape the analysis so it reflects how your team understands the system.

Set the target architecture

3

Your architects and the engineer use the evidence to draw domain boundaries and decide what to preserve, change, or retire. Whether it’s microservices, a modular architecture, or replatforming: the target is whatever the evidence supports or the team needs.

Generate the specs and tests

4

vFunction generates per-domain specifications backed by observed behavior, refactoring prompts, and integration tests from production flows. The engineer tunes them against your codebase.

Make the changes, one domain at a time

5

Kiro, Claude Code, AWS Transform, GitHub Copilot, and others make the changes over vFunction’s MCP server. The engineer and your team review and test each change in your environment before the next domain.

Your team takes over

6

As confidence builds, your team does more and the engineer does less, until your team runs the process on its own and checks in as needed.

The engineer

Who the forward-deployed engineer is

A solution architect who is onboarded into your environment and works as part of your team, with three kinds of experience at once.

Applications like yours

Has modernized large Java and .NET systems before, and knows how to join the vFunction analysis with the team’s picture of the system.

What the analysis shows

Reads vFunction’s runtime evidence and shapes it to your domains while identifying the tangles it unveils.

AI against a real codebase

Directs Kiro, Claude Code, AWS Transform, GitHub Copilot, and others systematically across a real, messy codebase, and helps you review what comes back.

What you supply

What we need from your side

The engagements that move fastest are the ones where the application owner treats the engineer as part of the team.

Access

The codebase, the environment where the application runs, and the people who know the domain.

Domain knowledge

The business knowledge the code doesn’t carry. The application owners work with the engineer to understand the domains as the analysis unfolds.

Review and testing

Every change reviewed and tested in your own environment, by your team, before the next domain.

Someone who clears blockers

An access grant, a repository seat, a developer assigned to a task, when it’s needed to drive rapid progress.

Let's talk

Tell us about the application.

What you’re looking to modernize, roughly how large it is, and where it runs today. That’s enough for us to come back with how an engagement on it would run.

What happens next

  1. A person reads it, not a scheduler.
  2. You hear back from someone who can answer your questions about the application.
  3. If it’s a fit, a conversation with an engineer who has modernized applications like yours.
Where judgment stays with people

vFunction shows what executes. Your team decides what should.

A database table nobody observed in production, a dependency that looks dead, a class shared by two domains: the engineer takes those to your team before anything is removed. The analysis is an input to a conversation, not an instruction set.

When the engineer hits something the platform doesn’t handle in your codebase, it goes back to vFunction’s product team and is triaged into the product, not into a one-off customization for you.

Questions people ask about engagements

Is this professional services?

No. It is engineers running a repeatable process with your team and transferring it. There is no bespoke build, and the platform is the same platform every customer runs.

How long does an engagement take?

It depends on the application and on how quickly decisions get made on your side. We don't publish durations, because the honest answer for a specific application comes after we have seen it run.

Where does the work happen?

In your environment. The engineer is onboarded into your codebase, your test environment, and your team. Nothing leaves for a lab.

Who writes the code?

Your AI coding tools generate the changes from vFunction's specifications and prompts. The engineer directs them and reviews the output with your team, and your team tests every change in your own environment before the next domain.

Which AI coding tools does this work with?

Kiro, Claude Code, AWS Transform, GitHub Copilot, and others, connected to vFunction through its MCP server.

Do we need to have decided on microservices?

No. Many engagements end in a modular application or a refactored and replatformed one. Your architects decide the target from the evidence.

What if we have no tests?

vFunction generates integration tests from observed production behavior, so the safety net exists before the first change.

Can our team run this without vFunction's engineers?

That is where every engagement is meant to end. Teams that have completed an engagement run their own refactoring process and check in with their engineer periodically.

How does an engagement start?

With a conversation about the application: what it is, roughly how large, and where it runs. A person replies, and if it's a fit, you talk to an engineer who has modernized applications like yours.

Tell us about the application

Java or .NET, roughly how large, where it runs, what needs to change. We come back with how an engagement on it would run.