How to Become a Business Analyst in IT From Another Domain
A practical roadmap for moving into business analysis from a non-tech background, what to actually learn, and how to use AI to close the gap in weeks instead of years.
I have spent over a decade in banking and payments, and I have hired, onboarded, and worked alongside a lot of business analysts. Some came up through IT. Plenty did not. The single most common question I get from people outside tech is some version of: can I actually move into a BA role in IT if my background is teaching, nursing, retail, accounting, operations, or something else entirely?
Yes. And the path is shorter and more direct than most people make it sound. The problem is not your aptitude. The problem is that nobody has told you what the job actually is underneath the jargon, and which specific things you need to learn versus the mountain of theory you can safely ignore.
So let me lay it out the way I would explain it to someone sitting across from me who is serious about making the jump. I also put together a free sample of what a BA actually does day to day, which is the fastest way to see whether this role fits how your brain already works.
First, understand what the job really is
The biggest misconception about business analysis in IT is that it is a technical role. It is not. It is a translation role.
A business analyst sits between people who have a problem and people who can build the solution. The people with the problem speak in outcomes and frustrations. The people who build speak in systems and constraints. The BA takes a vague, half-formed business need and turns it into something precise enough that an engineer can build it and a tester can verify it.
If you have ever calmed down an angry customer, taught a confused student, coordinated a chaotic event, or untangled a billing dispute, you have already done the hardest part of this job. You listened to someone who could not articulate their own problem, figured it out anyway, and turned it into action. That is requirements elicitation. We just pay more for it in tech.
Some of the sharpest analysts I have worked with did not come from computer science. One had been a nurse. She was unbelievable at asking the question behind the question, because in her old job the patient who said “my arm hurts” sometimes meant something completely different. That instinct is worth more than knowing what a REST API is. The API you can learn in a weekend.
What you actually need to learn (it is less than you fear)
Let me be straight with you, because the internet is full of people selling a six-month bootcamp for something that takes a few focused weeks of the right material.
You need to understand, at a working level, how software gets built and delivered. Not how to build it. How it flows. You need to know what a requirement is, the difference between a functional and a non-functional one, what a user story looks like, and what “done” means to a development team. You want to be comfortable reading a simple database query, because at some point someone will say “can you check if that data is actually in the system,” and you want to be the person who answers instead of the person who files a ticket and waits three days.
In banking specifically, you will run into payment message standards, settlement timing, and reconciliation. Nobody expects you to know ISO 20022 on day one. They expect you to be the kind of person who, when handed a 200-page message specification, does not panic. You read it slowly, you map it to the business problem, and you ask good questions. That is the whole game.
This is the trap most career switchers fall into: they either over-prepare on theory they will never use, or they show up with zero vocabulary and get talked over in every meeting. The fix is knowing precisely which concepts come up in real work. That free What Is a BA sample lays out the real day-to-day so you can stop guessing what to study.
Your old domain is your unfair advantage, so stop hiding it
When people from another field ask me how to present their background, they almost always want to know how to downplay it. Do the opposite.
Get Ahmed Squalli’s stories in your inbox
Join Medium for free to get updates from this writer.
If you were a teacher, you ran a room full of people with different needs and kept them all moving toward an outcome. That is stakeholder management. If you worked in retail operations, you have lived inside process inefficiency and you know exactly what it costs when a system makes a frontline worker’s job harder. That is empathy a lot of pure-IT analysts never develop, because they have never had to use the bad software they help build. If you came from finance or accounting, you already understand the domain that fintech and banking are built on top of, and domain knowledge is the single hardest thing to teach a new analyst.
I once interviewed two candidates for a BA role on a payments platform. One had three years as a junior analyst at a software company. The other had spent eight years in retail banking operations, dealing with failed transactions and customer complaints, and had taught herself the technical basics on the side. I leaned toward the second one without much hesitation. She already understood why a payment fails, what it does to a customer, and what the bank cares about. The technical layer was the easy part to add. The domain instinct was not.
Write your resume so your old experience reads as relevant, because it is. “Resolved escalated billing disputes” becomes “investigated root-cause issues across systems and stakeholders and documented resolutions.” Same work, honest framing, spoken in the language of the role you want.
Use AI to close the gap faster than anyone could before
This is the part that genuinely did not exist a few years ago, and it is the single biggest reason a motivated switcher can move fast in 2026.
You now have a tireless tutor that will explain any technical concept at exactly your level, as many times as you need, without judgment. When I onboard onto a new system, I use AI assistants constantly. I paste in a chunk of an API specification and ask it to explain each field in plain English. I describe a vague business request and ask it to help me draft clarifying questions before a meeting. I hand it a sample dataset and ask what a SQL query would look like to pull what I need, then I run it and learn by doing.
For someone coming from another domain, this changes the math entirely. The thing that used to take a year of sitting next to a senior analyst, absorbing the vocabulary and the patterns and the “why we do it this way,” you can now compress dramatically by asking good questions to a model that has effectively read everything. If your team uses tools like GitHub Copilot, you get this assistance directly inside the environment where the work happens, which is even better.
Here is the catch, and it matters: AI makes you faster, not correct. It will confidently tell you wrong things. Your value as a BA is judgment, knowing which answer is right, which requirement actually matters to the business, which edge case will blow up in production. AI handles the lookup. You handle the thinking. The analysts who win are the ones who use it to learn the boring parts fast so they can spend their energy on the parts that require a human who understands people and consequences.
If you want a structured way to actually use AI in this role rather than chatting with it at random, I built The Technical BA Prompt Toolkit around the exact workflows I use on banking projects.
A realistic first 90 days
Do not try to become a senior analyst before you have the title. Aim to be useful, fast.
In your first weeks, your job is to learn the system and the people. Map who owns what. Sit in every meeting you can. Ask the questions you are embarrassed to ask, because the new person gets a grace period and that window closes quickly. Write down every acronym and look it up. Build a personal glossary. You will be surprised how fast the fog lifts once you have a hundred terms defined in your own words.
Then start adding value where you already can. You can take meeting notes that are actually useful. You can chase down an answer nobody else has time for. You can write up a process the team has been running on tribal knowledge for years. None of that requires deep technical skill, and all of it builds the trust that lets you take on bigger work.
The technical depth comes with reps. You do not need it on day one. You need it by month six, and you will get there if you stay curious and stop being afraid of the things that look complicated. A payment flow diagram is not complicated once someone walks you through it once. A database is not magic. Code is just instructions, and you can read instructions.
You are more ready than the imposter voice is telling you
The people who make this switch successfully are not the ones with the most technical background. They are the ones who decided their domain experience was an asset instead of a liability, learned the specific vocabulary the job actually uses, and were not too proud to ask questions while they ramped up.
If you take one thing from this, take this: the job is translation, and if you are coming from another domain, you have probably been translating between confused humans and rigid systems your entire working life. You are just about to start getting paid properly for it.
Start with the free What Is a BA sample to see the real day-to-day, and if you are aiming specifically at the highest-paying corner of this field, Break Into Banking is the full roadmap I wish someone had handed me.
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.
