Robert Encarnacao
AI transformation leadership
Also offered · Software portfolio analysis
Modernization programs get approved on a story: what the system does, how bad the code is, how long a rewrite would take. The story is usually wrong in two or three places that matter, and nobody finds out until the budget is spent.
This is a service I offer alongside my main work in AI transformation leadership. It comes from fifteen years of leading the assessments that come before the money: two to four weeks of reading the code, working sessions with the people who live with it, and a decision both sides can defend. Single applications and whole portfolios, from VB6 and PowerBuilder to multi-million-line suites.
If you are deciding what to do with a legacy estate, this is how I would run the assessment. The panel shows how a portfolio gets triaged, and what changes once the code is read.
The steps never change. What goes into them is tailored to the company, the people in the room and the project that follows.
Who owns the code, what it does, where they want to take it, how much help they want, and who signs. Seven questions every time, then as much background as the conversation allows.
Which applications, how large, which screens get a proof of concept, how long it takes and what it costs. Anything vague here becomes an argument in week three.
The company's goal, each stakeholder's goal, and the decision the assessment must support, checked against each other. Then onboarding, the right people booked, and a first scan of the code before anyone meets.
No kick-off until the build compiles and runs, the goals agree and the right people are booked.
Why now, what has been tried before, what success looks like, and who is quietly against it. Confirm the agenda and which add-on modules apply.
A fast technical demo, not a training session. Current architecture, testing and release, the target, and the business constraints, with a checkpoint at the end of every day.
Automated scans of the whole codebase, a trial migration, a proof of concept on the hardest screens, and a manual deep dive wherever the risk actually lives.
The customer confirms the findings before anything is priced. Then come the report and the options.
Every customer gets the core. Add-ons join only when the first call or the first scan says they matter.
Protect the roadmap.
Release cadence, what customers will notice, and a team that keeps shipping while the platform moves.
Change nothing users can see.
Like-for-like behaviour, minimal retraining and a cutover nobody notices.
Draw the lines clearly.
A fixed scope, known dependencies and a clean boundary between their work and ours.
Get them ready, then step back.
The tooling, a readiness check and a second opinion on the plan.
The decision is made one application at a time, while looking at the whole estate.
Size, languages, owners and dependencies for every application, including the ones nobody admits to owning.
Shared code is often a large part of the total. It changes the order of everything, so it is mapped before anything is scored.
How unique is it to the business, how fast must it change, and how sound is the code. Asked in that order.
Migrate, rewrite, replace or sustain. Doing nothing is a legitimate answer, as long as it comes with a date.
Shared code first, the longest job started early, and the rest in parallel as far as testing capacity allows.
The panel at the top runs steps three to five on an eight-application sample. Try it yourself.
In the order they tend to get broken.
No kick-off before the build works. An assessment that starts without compiling code and complete source spends its budget waiting.
The first story is a hypothesis. When the code disagrees with the meeting, the code wins and the plan changes.
Line up the goals before the first session: the company's, each stakeholder's and the assessment's own. Otherwise the report answers the wrong question.
Confirm before you price. The customer signs off the inventory and the findings, so the estimate rests on facts both sides accept.
The same discipline, applied to a wider question each time.
Line counts, control mappings and effort by phase. The question was how to convert.
Strengths set next to risks, written for the people who would live with the result.
A single report structure, automation readiness measured rather than promised, and every assumption written down.
Several target options side by side, AI-assisted code transformation where no tool exists, and security and compliance mapped.
The same method, whichever side of the table you are on.
The applications you are weighing, even a rough list with sizes and languages. You get a written read on where I would look first, whether or not anything follows.
Pick a step or a rule on this page and ask what happens when someone skips it. Thirty minutes is enough to find out whether this is how you want the work done.