From Developer to Business Analyst: Trading Code for Scope Without Losing Your Edge

A developer who moves into business analysis should target a technical BA or systems analyst role, not a generic BA role, because those roles pay for the code, API, and SQL skills you already have. The move usually costs money at first: senior developer to senior BA is often a 10 to 25 percent base pay cut in the US, smaller in Europe, and a senior technical BA role in banking narrows or closes the gap. What transfers is technical; what you must learn is elicitation, writing for non-technical readers, and resisting the urge to design the solution in the first meeting.

The first week a senior Java developer joined one of my programs as a technical BA, he ran a workshop with the head of payment operations. Within ten minutes he had drawn the database schema for the new returns table on the whiteboard, with column names. The head of operations nodded politely, left early, and sent a delegate to every session after that. Nothing he drew was wrong. He had simply answered “how” before anyone had agreed “what”, and the person who knew “what” decided the meeting was not for her.

Six months later he was one of the strongest analysts I have worked with, because he learned to hold the design back until the requirement was agreed, and then use his technical depth to test it. That skill, turning a vague business request into a specification a developer can build without it becoming a design document, is the one I wrote From Vague BR to Functional Requirements to teach, with banking examples.

Why do developers move into business analysis?

Developers move into business analysis for three reasons I hear over and over: they want more say over what gets built, they prefer people and decisions to tickets, or they are worried that AI will commoditise the coding part of their job. The first two are good reasons. The third needs care.

AI does compress code production, and I wrote about what that does to the developer’s job in developer skills in the AI era. But it compresses routine analysis too: drafting stories, summarising meetings, generating test cases. Moving seats is a hedge only if you move toward the parts of the work AI does not sign, which are scope decisions, trade-offs between stakeholders, and verification against intent. The broader picture of which analyst roles are exposed is in is business analysis a safe career with AI, and every route between the seats is on the career paths page.

What does the move from developer to technical BA actually look like?

The day changes from building a known thing to deciding what the thing is. The difference between the seats is well described in technical BA vs software engineer: code stops being your product and becomes one of your tools.

As a developer you…	As a technical BA or systems analyst you…
Receive a refined story and build it	Produce the refined story from a vague request and several people who disagree
Are judged on working code	Are judged on whether the right thing was built and the team understood it
Read the codebase to change it	Read the codebase to find out what the system really does today
Call an API to integrate with it	Read the API contract against the requirements and find the gaps first
Write SQL to build features	Write SQL to prove a rule holds in production data
Debug your own defects	Triage defects and decide with the business which ones block release
Talk mostly to engineers	Talk to operations, compliance, product, vendors, and engineers, in their language

If you want a middle position that keeps more code, the developer analyst uses scripts and automation to verify analysis; the comparison with a backend role is in developer analyst vs backend developer.

What transfers from development to business analysis?

Four developer skills transfer directly and are why technical BA roles pay more than generic BA roles:

• Reading code. You can answer “what does the system do today when the amount is zero?” by reading the service, not by asking three people.
• APIs. You can read an OpenAPI contract, spot a missing error response, and send the request yourself.
• SQL. You can check whether a proposed rule would have matched last month’s data before anyone builds it.
• Debugging. You know how to isolate a cause, which makes you strong in incident analysis and defect triage.

What does not transfer from development to business analysis?

Four things do not transfer, and the new job is judged mostly on them:

• Elicitation. Stakeholders describe symptoms and solutions, rarely needs. Getting from “we need a report” to “we need to know by 10:00 which payments missed the cut-off” takes questions, not code.
• Writing for non-technical readers. A compliance officer must be able to sign your requirement. If it contains a class name, she cannot.
• Living with ambiguity. A developer resolves an open question by making a decision in code. An analyst leaves it open, visibly, until the person who owns it decides.
• Not solutioning too early. The single hardest habit to break. The difference between a story and a specification, and how much detail each needs, is covered in user story vs specification.

How much does a developer lose moving to business analysis?

Most developers take a base pay cut when they move to business analysis, and how much depends on the target role and the market. The figures below are indicative 2026 base salaries for permanent roles in large cities, excluding bonus and equity.

Role	US (USD)	Canada (CAD)	UK, London (GBP)	Eurozone (EUR)
Software developer, mid (non big tech)	110k to 145k	95k to 125k	55k to 75k	55k to 70k
Software developer, senior	140k to 180k	120k to 155k	75k to 100k	70k to 90k
Business analyst, senior	110k to 135k	90k to 110k	55k to 72k	60k to 75k
Technical BA, mid	95k to 125k	80k to 100k	50k to 65k	52k to 65k
Technical BA, senior	125k to 155k	100k to 125k	65k to 85k	65k to 82k
Systems analyst, mid	90k to 115k	78k to 98k	45k to 58k	50k to 62k
Systems analyst, senior	115k to 140k	98k to 120k	58k to 75k	62k to 78k

The honest reading:

• Senior developer to senior BA is often a 10 to 25 percent cut in the US. The bands barely overlap: the top of the senior BA band sits below the bottom of the senior developer band.
• Senior technical BA narrows the gap, and in banking and capital markets in New York or London, which typically add 10 to 20 percent, it can close it.
• In Europe the difference is smaller. A senior developer in the Eurozone at €70k to €90k and a senior technical BA at €65k to €82k overlap heavily.
• Big tech is a different conversation. Senior engineer total compensation there runs US$250k to US$450k with equity; no analyst band comes close, and anyone leaving it for analysis is choosing the work, not the money.
• Long term, analysis has its own ceiling. Lead or principal technical BAs earn US$150k to US$180k, and the routes into product and architecture are open. The analyst salary guide has every band.

To verify 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. Use ITJobsWatch in the UK, the annual Robert Half, Hays, and Michael Page guides, Levels.fyi where equity matters, and two people one level above you.

What does a developer to analyst move look like in real cases?

The cases below are composites of moves I have watched on delivery teams, with details changed.

Julien: Java developer at a bank in Paris to technical BA

Start: senior Java developer on a payments platform, €72k, seven years in the bank, tired of being handed specs he disagreed with. What he built (8 months, internal): the functional specification for a SEPA Instant change on his own team, written with the BA as reviewer; two workshops he facilitated with operations; the UAT scenarios for the release. First role: senior technical BA on the bank’s ISO 20022 program. New pay: €70k, inside the senior technical BA band at the French end of the Eurozone range, a cut of about 3 percent. What he would do differently: stop proposing the design in workshops sooner. It cost him a stakeholder’s trust in his first month.

Sarah: burnt-out front-end developer in Vancouver to product-facing BA

Start: mid-level front-end developer at a fintech, C$108k, exhausted by release pressure and wanting to work with users. What she built (6 months): notes from eight customer interviews she ran with the product manager, a mapped onboarding journey with drop-off points from analytics, and acceptance criteria her team used for two sprints. First role: business analyst on the customer onboarding team at a different fintech. New pay: C$88k, near the top of the mid BA band, a cut of about 19 percent. British Columbia’s posted ranges let her see it before applying. What she would do differently: apply for technical BA roles on front-end heavy products too. Mid technical BA roles sit at C$80k to C$100k, and her component knowledge was worth more than she charged for it.

Dave: mid-level .NET developer in Chicago to systems analyst

Start: mid-level .NET developer at an insurer, US$128k, five years on policy administration integrations. What he built (5 months): a sequence diagram of the policy to billing flow drawn from logs, a data mapping for a new vendor API, and a list of twelve contract gaps the vendor fixed before build. First role: senior systems analyst at a different insurer. New pay: US$120k, inside the senior systems analyst band, a cut of about 6 percent. What he would do differently: negotiate from the posted range. Illinois requires one, and he accepted the first number without asking where it sat.

Interviewers for these roles probe one thing hard: can you leave the design alone? The questions they use, what each one tests, and how to answer from real work are in The BA and Technical BA Interview Guide. The “why the switch?” answer in particular is covered in interviewing as a career changer.

What mistakes do ex-developers make as business analysts?

Ex-developers make five predictable mistakes as analysts, and each one stalls the move:

• Writing the design instead of the requirement. “Add a nullable column return_reason_cd to payment_txn, populated from RtrRsnInf/Rsn/Cd” is a design. “When a payment is returned, the system must store the return reason code from the return message and show it to operations on the payment detail screen” is a requirement. The field path belongs in the data mapping; the table does not belong in the requirement at all. The full decomposition is in from business requirement to functional spec.
• Impatience in workshops. Finishing stakeholders’ sentences, jumping to the whiteboard, or saying “that is easy” to a person who has lived with the problem for five years. Let the silence run.
• Gold-plating. Specifying the elegant general solution when the business asked for one case. Your requirement becomes the scope, and scope is cost.
• Hiding in the technical work. Spending every afternoon in the code because it feels productive, while the stakeholder session you should be preparing goes unprepared.
• Undervaluing the new craft. Treating requirements as “just documentation”. The analysts who get promoted treat a specification with the same rigour as production code.

What is the plan to move from developer to technical BA?

Three to six months on your current team is enough if each step leaves an artifact. Before you start, score yourself on the technical analyst skill matrix and look at the roadmap to see which analyst skills are already green.

1. Weeks 1 to 2: pick the target. Decide between technical BA, systems analyst, and generic BA using the table above. Artifact: a one paragraph target statement and a list of your three weakest analyst skills.
2. Weeks 3 to 6: write one specification with no implementation detail. Take a ticket your team will build and write the requirement, business rules, and acceptance criteria. Ask the BA and a QA analyst to review it. Artifact: a reviewed spec that names no table, class, or endpoint that does not already exist.
3. Weeks 5 to 8: run one elicitation session. A stakeholder interview or a refinement session you lead. Write the decisions log. Artifact: the log, with open questions and owners.
4. Weeks 7 to 10: write for a non-technical reader. A business impact summary or release note for a change you shipped. Artifact: a document an operations lead signed off without asking you what it meant.
5. Weeks 9 to 12: own acceptance and UAT. Write the UAT scenarios for a feature and support the business through them. Artifact: a UAT sign-off with your scenarios attached.
6. Months 4 to 6: make the move. Take the artifacts to your manager or the program’s BA lead, rewrite your CV around analyst outcomes, and prepare the interview. Artifact: an agreed internal move or a shortlist of external roles. The internal route is usually cheaper; see changing role inside your company.

If you need models for what those artifacts look like on a real project, Real-World BA Deliverables (20 Templates) has specs, test cases, and process maps from banking projects.

How can a developer practise analysis without changing jobs first?

A developer can practise analysis on a realistic system and keep the output as evidence. The Labs mission Analyze a payment API is the natural first step: you read an OpenAPI contract against requirements, sample responses, and business rules, and produce a gap register before integration starts. Developers read the contract quickly; the exercise is writing each gap as a question the API team can answer in one line, without proposing the fix.

The missions follow the Become a Technical Analyst track. A free account saves your progress and unlocks each solution, so you can compare your gap register with mine. For the full technical analyst route from any starting point, read how to become a technical business analyst. If you later want to go back, the reverse move is in from technical analyst to software developer.

The takeaway

A developer who becomes a business analyst trades code for scope, and the trade works best when the target is technical BA or systems analyst. Expect a cut in the US, a smaller one in Europe, and a gap that narrows in banking. Your technical depth is the edge; the job is judged on elicitation, clear writing, patience with ambiguity, and the discipline to specify what before how. Build those on your current team, keep the artifacts, and the move becomes a conversation rather than an application.

To learn the core skill, turning a vague request into a spec without writing the design, start with From Vague BR to Functional Requirements. If you want to test your plan or your “why the switch?” answer with someone who has hired analysts, book a 1:1 Tech BA Coaching Call. Grab the free downloads, or browse everything at The Tech BA Toolkit. More on the coding side of analysis lives in the Developer Analyst hub, and the requirements side in the Business 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, Software Development, Career Change, Technical Business Analyst, Banking