How to Position Yourself as a T24 Migration Specialist

At some point in your T24 career, you have probably been close to a migration. Maybe you were on a project that was mid-way through a TAFC-to-TAFJ transition. Maybe you supported an environment that had recently cut over and was still discovering, with a kind of grim regularity, exactly which parts of the TAFC runbook did not apply anymore. Maybe you watched a go-live get delayed three times from the inside while various senior people explained that the situation was under control in the specific tone that means it absolutely was not.

That experience is worth considerably more than most T24 professionals realise. And most of them are not presenting it well.

Why migration expertise commands a premium right now

Here is something the Temenos documentation does not prepare you for: the hard part of a TAFC-to-TAFJ migration is not the compilation. The compilation is, in the grand scheme of things, the part that eventually works. It complains loudly, it produces errors in quantities that suggest it is trying to set a record, and then it works.

The hard part is everything that changes behaviour quietly. Selection logic that returns nothing and does not mention why. Descriptor handling that is subtly different in ways that are not documented anywhere you will find quickly. COB monitoring runbooks that are faithful copies of the TAFC originals, right down to the log file paths that no longer exist. JVM heap settings configured by someone who entered what felt like a reasonable number and then left the project.

Banks are paying a meaningful premium for people who have already made these mistakes somewhere else. Not because the knowledge is rare in the abstract, but because it is rare attached to actual consequences. Anyone can read the Temenos documentation. The person who watched a COB fail on day three of go-live because the monitoring runbook still pointed at TAFC log directories — that person has something the documentation cannot give you.

The migration wave is still in progress. Banks that started two years ago are still in it. Banks that have not started are watching the others with a mixture of sympathy and relief, and trying to hire people who have already learned the expensive lessons. The window for this positioning is open now.

What banks actually need from a migration specialist

The job description says TAFJ experience required. This phrase, like most job description phrases, contains less information than it appears to. What it usually means is one of three things, and they are quite different things:

Technical migration competence. You can manage a codebase through the compilation pipeline, resolve descriptor failures, and handle the transition from SELECT to DBTools without needing anyone to explain what DBTools is or why its default 200-row limit will eventually surprise someone at a critical moment. You know what tCompile and tIntegrate do. You know why the JAR did not update when you edited the source. You have, at minimum, a working relationship with Eclipse.

Operational migration knowledge. You understand what changes in the runtime environment after the technical work is done — JVM behaviour, log file locations, service restart sequences, the difference between how you monitored COB in TAFC and how you monitor it in TAFJ — and you can write runbooks that reflect the actual environment rather than the previous one with cosmetic changes. You know which things will break quietly in batch after go-live and you have already put them on the checklist.

Migration risk management. You know what goes wrong, when to say stop, and how to have that conversation with someone who has a contractual go-live date and a very strong preference for not hearing it. You can look at a readiness assessment and identify the gaps the project team has been tactfully not mentioning. This is the rarest of the three and the one that commands the highest rates.

Most candidates present themselves for the first category. The ones who can credibly cover the second and third are having different conversations about their contracts. Banks are not struggling to find people who can run the compilation pipeline. They are struggling to find people who understand what happens to a bank operationally when the technical migration is declared complete and the project team goes home.

The three knowledge layers that matter

It is a useful exercise to think about migration expertise in three layers, not because reality is this tidy — it is not — but because it helps identify where your depth actually sits and where you might be thinner than you think.

The technical layer — the mechanics. The jBC compilation pipeline from source through tCompile, tIntegrate, and tMerge to a deployed JAR. DBTools as the SELECT replacement: what it does differently, what modes exist, and why the 200-row default will eventually cause someone a difficult afternoon. Descriptor behaviour changes between TAFC and TAFJ. JVM basics: heap sizing, garbage collection, connection pools, and the startup and shutdown sequences that ideally someone has written down. Eclipse or Design Studio for making and deploying changes in a way that actually takes effect.

The operational layer — what changes in daily practice. Where TAFJ log files actually live and what they look like. COB monitoring via Grafana rather than the traditional approach of refreshing a screen and hoping. How to restart a TAFJ application server safely and what to verify before declaring the situation resolved. What breaks silently in batch after migration: date handling, DICT-field-driven SELECT logic, derived field behaviour that was always slightly fragile and is now slightly fragile in a different way. Environment drift — the quiet, patient way that TAFJ environments gradually diverge from each other until one of them does something unexpected.

The strategic layer — what makes migrations succeed or fail.What to test that teams routinely skip, usually because it is inconvenient to set up and nobody has officially said it is required. Local developments as the highest-risk migration category — old code, written by people who have since moved on, doing things that made complete sense at the time. Interface testing gaps: file formats, character encoding, timing changes caused by COB schedule differences that nobody thought to check. The distinction between a technically successful migration and an operationally ready one. How to frame a go/no-go decision and who needs to be the person who actually says the word.

Most T24 professionals have depth in the technical layer. The strategic layer is where experienced people can genuinely differentiate — and it is also where hiring managers spend most of their attention, because it is the layer that determines whether the project lands safely or produces a post-incident review document of remarkable length.

How to frame your experience in practice

In a CV or interview, migration experience is often described in a way that technically conveys information while managing to say almost nothing useful.

The weak version sounds like this:

"Involved in a TAFC-to-TAFJ migration project."

This tells the reader nothing. It could mean you were central to a complex migration over eighteen months. It could mean you attended stand-up calls for six months, occasionally nodded, and kept the Jira board tidy. The hiring manager, who has been doing this long enough to recognise the construction, will assume the latter until proven otherwise.

The stronger version names what you actually did and attaches an operational consequence to it:

"Led the compilation and deployment process for a TAFJ migration, including diagnosing DICT-field-related SELECT failures in batch routines and rewriting local code to function correctly in the Java runtime."

"Designed the COB monitoring runbook for a post-migration production environment, identifying monitoring gaps between TAFC and TAFJ and establishing first-response procedures for the operations team in the weeks after go-live."

"Served as the point of escalation for go-live readiness decisions during a TAFJ migration, including defining rollback triggers and managing the stakeholder conversation when the testing window was compressed to a degree that made everyone uncomfortable."

The pattern in each case: what you did, in operational terms, with the consequence or context attached. Not a job title or a module name. A specific problem you owned and what you did about it. The hiring manager has seen ten CVs this week that say TAFJ experience. Yours should be the one that makes them put down their coffee.

If you were adjacent to a migration, not central to it

Not everyone has led a migration. A significant number of experienced T24 professionals have been close to one — on the same project, supporting a team that was doing the heavy lifting, or responsible for testing and operational validation rather than the technical design. This is a completely reasonable place to have been. Most migrations are too large for one person to have touched everything.

Adjacent experience is still useful experience. The honest framing is:

"I worked alongside the migration team during a TAFJ cutover and was responsible for validating that the operational procedures were correct for the new environment — specifically around COB monitoring and the first-line response to TAFJ application server failures."

What makes this credible is the specificity. You know what changed. You know what the new environment required. You know where the gap was. The fact that you were not the project lead is not the disqualifying detail it might feel like.

If your migration exposure is primarily from the support side — handling incidents in the first weeks after go-live, dealing with the things the project team missed or politely deferred to BAU — that is arguably the most useful perspective of all. The project team saw the migration from the inside, under optimistic assumptions and significant time pressure. You saw what it produced when it met production. Those are different and complementary views, and the second one translates directly into the strategic knowledge that hiring managers are actually trying to find.

The positioning mistakes to avoid

Focusing only on the technical. Migration expertise that stops at jBC compilation is the table stakes — the minimum required to be taken seriously, not the thing that gets you a better contract. Banks are not short of people who can run the compilation pipeline. They are short of people who understand what breaks operationally after the pipeline has done its job and the project has declared success.

Describing TAFC experience as migration experience.Knowing TAFC deeply is genuinely valuable. It is not the same as having navigated the transition to TAFJ. If you have extensive TAFC knowledge and limited TAFJ experience, say so honestly: "My experience is primarily in TAFC environments — I have a clear understanding of what the migration requires and what changes operationally, and I am actively building hands-on TAFJ depth." That is a credible position and most hiring managers will respect it. Claiming TAFJ migration expertise you have not got, in a community where the person interviewing you may well have worked at the same bank, is a different matter entirely.

Overclaiming on things that are checkable. The T24 professional community is, by the standards of most enterprise software ecosystems, extremely small. It has the slightly unnerving quality of a village — everyone either knows each other or knows someone who does. Specific project claims, specific time periods, specific environments: these are the kinds of details that occasionally come back to haunt people in unexpected ways.

Not knowing the standard failure points. If you claim migration expertise and cannot answer "what are the most common things that break in production after a TAFJ cutover?" without significant hesitation, you will lose credibility quickly. The expected territory includes: COB monitoring gaps, local development failures, JVM heap under-sizing, interface timing changes, and SELECT/DBTools behaviour differences. These are the canonical pain points. Anyone who has genuinely been close to a migration has seen at least one of them in person and has a view on it. If you cannot speak to any of them specifically, the claim does not hold, and experienced interviewers will notice within about two questions.

Building the depth deliberately

If you are still building your TAFJ migration expertise rather than already having it, the most efficient path is to focus on the operational and strategic layers first. The technical mechanics are learnable with reasonable speed given a working environment. The operational knowledge — what actually changes in daily practice after a go-live — requires either direct experience or a deliberate effort to learn from people who have it.

The questions worth being able to answer in detail, without notes, in a way that suggests you have thought about them because you had to rather than because you read them somewhere:

• What is the difference between how COB failure is monitored in TAFC and TAFJ, and what does a team need to set up before go-live to have any chance of seeing a problem before it becomes an incident?
• What makes local developments the highest-risk migration category, and what specifically should be tested that projects routinely do not get around to?
• What SELECT behaviour differences can cause batch jobs to produce incorrect output in TAFJ without raising an error?
• What does a sensible go/no-go decision framework look like for a TAFJ migration, and — more importantly — who should own the decision and what gives them the standing to make it stick?
• What are the most common things that go wrong in the weeks immediately after go-live, and what do they usually indicate about what the project underestimated?

Being able to answer those questions with operational specificity — not just module names, but the actual texture of what goes wrong and why — is what migration specialist positioning actually requires.

The market for this expertise is real. The supply of people who can genuinely cover all three knowledge layers is still limited. And the migrations currently in progress at banks around the world mean the timing is about as good as it is likely to get. The gap, in most cases, is not knowledge. It is presentation.