From Operations or Production Support to Business Analyst: The Most Reliable Route In

Moving from operations, production support, or the service desk into a business analyst or technical BA role is the most reliable route into analysis, because you already know how the system fails. The typical move is internal, takes 6 to 12 months of deliberate work, and usually pays: a payments operations analyst in a US major metro on about US$55k to US$75k base can land a junior or mid technical BA role in the US$75k to US$125k range. What you lack is the analyst’s craft (requirements, facilitation, scope), and you can build all of it before you leave your current seat.

A few years ago I was running a requirements workshop for payment returns on an ISO 20022 migration. I had the happy path on the whiteboard: return received, original payment matched, customer account credited. A payments operations analyst from the exceptions team had been invited almost as an afterthought. Twenty minutes in she asked: “What happens when the return arrives after we have already credited the beneficiary manually? We see that about forty times a month.” Nobody in the room had the answer or the number.

That one question produced three requirements, a new reconciliation rule, and a test case QA had never considered. Nine months later she joined the program as a junior technical BA. I have watched that pattern more than any other move into analysis. If you are in operations and want to understand the banking side of that route, including the domain knowledge that unlocks premium pay, I laid it out in Break Into Banking.

Why is operations the most reliable route into business analysis?

Operations is the most reliable route into business analysis because it teaches the one thing projects cannot teach quickly: how the system behaves when reality disagrees with the design. An operations analyst knows that 3 percent of inbound payments arrive with a truncated creditor name and that a spreadsheet kept by two people is the real control.

Three things make the route reliable:

• The move is usually internal. The change program that is replacing your system needs someone who knows the exceptions. Hiring managers inside your company can see your work; strangers cannot.
• Your knowledge is scarce. Anyone can learn a notation; few know which 40 cases a month break the process.
• You already produce analyst artifacts. An incident summary is a root cause analysis; a workaround is a functional rule nobody wrote down.

This is the same argument I make on the career paths page: the best entry point is the one where your existing knowledge is the scarce input.

What does the move from operations to analyst actually look like day to day?

The work shifts from fixing today’s exception to preventing next quarter’s. In operations you are measured on queues cleared and incidents closed. As an analyst you are measured on whether the thing that gets built is right, which means your output is a document, a decision, or a test, not a cleared queue.

In operations or support you…	As a BA or technical BA you…
Clear an exception queue by hand	Define the rule that stops the exception being created
Work an incident until service is restored	Write the requirement and acceptance criteria that prevent the repeat
Know the workaround	Document the workaround as current state and design the target state
Escalate to the change team	Sit in refinement with the change team and answer their questions
Check balances in a screen every morning	Write the SQL query or reconciliation rule that checks them for you
Follow the runbook	Write the runbook, and the requirement behind each step

The biggest adjustment is ambiguity. A ticket closes; a requirement is done only when enough people agree on it, and producing that agreement is your job.

What do operations and support people already have?

Operations people already have four assets that most junior analysts lack:

1. Incident handling. You know how to stay calm, gather evidence, and write a timeline. That is the core of production support skills for analysts, and most project analysts are weak at it.
2. Exception queues. You know the categories, the volumes, and which ones matter. An analyst who can say “72 percent of repairs are missing structured addresses” gets listened to.
3. Real data. You have seen the payloads, the reference data, and the odd values that never appear in a test environment.
4. Undocumented workarounds. Every system has manual steps that exist only in someone’s head. Finding them is half of a current state analysis, and you already know where they are.

If you have traced a transaction across systems, you have done most of what I describe in how a technical BA investigates a failed payment. Reading logs by correlation id, covered in reading production logs, is a skill many analysts with five years on projects still lack.

What do operations people lack when they move into analysis?

Operations people usually lack three things, and all three are learnable:

• Writing requirements someone else can build. Operations says “the payment gets stuck”. A requirement says which field, which condition, which status, and what the system must do instead.
• Facilitation. Running a workshop with a product owner, two developers, and a compliance officer who disagree is different from escalating to a shift lead. You have to produce a decision, not just raise the issue.
• Scope. Operations people know every problem and want to fix all of them. An analyst has to decide which three make it into this release and write down why the others did not.

A useful test: write the requirement, with acceptance criteria, that would have prevented your last incident. If that takes more than an hour, that is your gap. Score yourself against the technical analyst skill matrix and the roadmap before you plan.

How much does a business analyst earn after moving from operations?

A move from operations into a business analyst or technical BA role is usually a pay gain, not a cut, which is rare among career moves. The figures below are indicative 2026 base salaries for permanent roles in large cities, excluding bonus.

Role	US (USD)	Canada (CAD)	UK, London (GBP)	Eurozone (EUR)
Payments operations analyst (starting point)	about 55k to 75k	about 50k to 70k	about 28k to 40k	not banded here
Customer support or service desk (starting point)	about 40k to 55k	about 40k to 55k	about 24k to 32k	not banded here
Business analyst, junior	65k to 85k	58k to 72k	32k to 42k	38k to 48k
Business analyst, mid	85k to 110k	72k to 90k	42k to 55k	48k to 60k
Technical BA, junior	75k to 95k	65k to 80k	38k to 48k	42k to 52k
Technical BA, mid	95k to 125k	80k to 100k	50k to 65k	52k to 65k
Systems analyst, junior	70k to 90k	62k to 78k	35k to 45k	40k to 50k

How to read it honestly:

• From payments operations, the typical landing is the junior technical BA band, which puts a US operations analyst on US$65k moving to about US$75k to US$95k. When your domain knowledge transfers directly, such as an ISO 20022 program that needs someone who knows the exceptions, the low mid band is realistic.
• From the service desk, the jump in percentage terms is the largest, because the starting band is lower. A service desk lead in the UK on £30k moving to a junior BA role in London at £32k to £42k can gain a third.
• The premium comes from two places: domain (payments, cards, insurance claims) and technical depth (SQL, logs, APIs). The first you already have. The second is what moves you from the BA row to the technical BA row, which is worth roughly 10 to 20 percent at the same level.
• Outside the big cities expect roughly 15 to 20 percent less in the UK and 10 to 20 percent less in smaller US metros.

To verify the band for your market, read posted ranges where the law requires them: New York, California, Colorado, Washington, Illinois, and several other US states; British Columbia since November 2023; Ontario since January 1, 2026 for employers with 25 or more employees; and EU countries as member states implement the Pay Transparency Directive. In the UK, check ITJobsWatch by keyword. The annual Robert Half, Hays, and Michael Page salary guides are useful cross-checks, and so is asking two people one level above you. The full table across 40 roles is in the analyst salary guide for 2026.

What does the move look like in real cases?

The cases below are composites of moves I have watched on delivery teams, with details changed. The numbers are consistent with the bands above.

Priya: payments operations analyst in Toronto to technical BA on an ISO 20022 program

Start: payments operations analyst at a large bank, C$62k base, four years on the wire repairs and returns queue. What she built (9 months): a process map of the returns queue with volumes per exception type, a SQL query against the operations data store that replaced a daily manual check of unmatched returns, and a written defect that became requirement RET-014 on the migration program. She also learned to read pacs.004 (the ISO 20022 payment return message) field by field. First role: junior technical BA on the same bank’s ISO 20022 program, an internal move. New pay: C$78k, near the top of the junior technical BA band. What she would do differently: “I waited too long to write things down as requirements. The exceptions I explained in meetings were forgotten; the ones I wrote up were built.”

Tom: service desk lead in Manchester to business analyst at an insurer

Start: service desk lead for a claims platform, £31k, running a team of six and owning the escalation process. What he built (14 months): a map of the top ten ticket categories with root causes, a knowledge article set that cut repeat tickets on one category by half, and a requirements pack for a self-service password reset change that he wrote with the project BA. First role: business analyst on the claims change team at a different insurer in Manchester, found after the internal route stalled. New pay: £35k, in line with a junior BA band adjusted for a city outside London. What he would do differently: stop being the person who fixed everything personally. His managers saw him as indispensable in support, which slowed the internal move.

Marcus: level 2 support engineer in Austin to systems analyst at a SaaS company

Start: level 2 (L2) support engineer on a billing platform, US$68k, strong on logs and database queries, weak on writing. What he built (7 months): three runbooks for the billing incidents he handled most often, a set of SQL checks that support now runs before escalating, and a sequence diagram of the invoice generation flow drawn from logs, which the engineering team adopted. First role: systems analyst on the billing team at the same company. New pay: US$88k, at the top of the junior systems analyst band for a metro slightly below the coastal markets. What he would do differently: practise writing earlier. His first specs came back with twenty questions each until he learned to write for someone who had not seen the incident.

If you are making your first formal move and need a week by week job search plan with examples of how to present indirect experience, Land Your First Job covers it through to day 90.

What is the six month plan to move from operations to analyst?

Six months is enough for an internal move if each month produces one artifact you can show; together they become your portfolio.

1. Month 1: map one exception queue. Pick the queue you know best. Draw the current process, including the manual steps and the spreadsheets, and add volumes per exception type for one month. Artifact: a one page process map with numbers.
2. Month 2: replace a manual check with a query. Find one check you or your team do by eye every day and write the SQL that does it. Start with SQL for analysts; a LEFT JOIN with WHERE right.id IS NULL finds most unmatched items. Artifact: the query, its output, and the hours saved per week.
3. Month 3: turn a defect into a requirement. Take a recurring incident and write it the way an analyst would: the condition, the expected behaviour, the acceptance criteria, and the test data. Send it to the change team. Artifact: the requirement, and ideally its ticket number once accepted.
4. Month 4: write a runbook. Pick the incident that wakes people up. Write the runbook with the evidence to collect, the queries to run, and the decision points. Artifact: a runbook other people use.
5. Month 5: get into a change project. Offer to help with UAT, a reconciliation rule, or a current state workshop on the program that affects your queue. Reconciliation design is a natural first contribution for payments operations people. Artifact: your name on a workshop output or a UAT sign-off.
6. Month 6: have the internal conversation. Take the four artifacts to the program’s BA lead or delivery manager and ask what the next analyst opening looks like. Update your CV at the same time with outcomes, not tasks. Artifact: an agreed move, or a clear list of what is missing.

Month 3 is the step that separates people who move from people who stay. For the technical skills behind months 2 and 4 (SQL, reading code, APIs, and delivery tools), I wrote The Technical Skills Guide for BAs for exactly this gap.

How do you practise analyst work if your team will not let you yet?

You practise on a realistic system outside work and keep the output as proof. The Labs are built for this. The mission Investigate a duplicate refund is the closest thing to an operations analyst’s day turned into analysis: a merchant ticket, API requests, logs, database state, and monitoring, and a deliverable that is an incident report with root cause and requirements. Operations people find the evidence fast; the practice is writing it up so a developer and a product owner can act.

The missions follow the Become a Technical Analyst track, in order. A free account saves your progress and unlocks the solutions and self-assessment, so you can compare your write-up against mine.

What mistakes stall the move from operations to analyst?

• Staying the hero. If every incident still routes to you, your manager has every reason to keep you. Document yourself out of the critical path first.
• Describing problems instead of writing requirements. “The system is slow at month end” is an opinion. “Batch job X must complete by 06:00 for 500,000 records” is a requirement.
• Applying only externally. Strangers cannot see your knowledge of the exceptions. Your own company’s change program can. See the playbook for an internal move as an analyst.
• Undervaluing the domain. Payments and claims knowledge carries a premium; do not accept a generic role that ignores it.
• Ignoring the technical track. If you already write SQL and read logs, aim at technical BA or systems analyst, which pay more at the same level. The route is in how to become a technical business analyst.
• Leaving your CV as a task list. Rewrite it around outcomes; the before and after bullets in rewriting your CV for a role change show how.

The takeaway

Operations and production support is the most reliable route into business analysis because the knowledge that is hardest to teach, how the system fails in real life, is the knowledge you already have. The move is usually internal, usually pays more, and rests on four artifacts: a mapped exception queue, a query that replaced a manual check, a defect that became a requirement, and a runbook. Build them in your current job first. If you are coming from outside tech altogether, start with switching careers into business analysis, and see the full career moves map for every other route.

For the banking and payments version of this route, including the domain knowledge that moves you into the higher bands, start with Break Into Banking. If you want a second pair of eyes on your move plan or your CV, book a 1:1 Tech BA Coaching Call. The free downloads are a good place to start, and everything else is at The Tech BA Toolkit. More on the role itself lives in the Business Analyst hub and, for the technical side, the Systems Analyst hub.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Career Change, Payments, Production Support, Banking