Moving into data analyst work from another field

What actually transfers

If you have spent years in finance, operations, marketing, teaching, or customer support, you already have some of this. Domain knowledge is the part hiring managers undervalue in job ads and overvalue in interviews: an analyst who understands what a churn rate means in a subscription business, or what a term means in a school's attendance data, gets to the useful question faster than someone who only knows the syntax. Spreadsheet fluency transfers directly — pivot tables, VLOOKUP/XLOOKUP, basic formula logic in Excel or Google Sheets is functionally the same skill as writing a GROUP BY in SQL, just less scalable. If your old job involved building reports for other people, reconciling numbers that didn't match, or explaining a metric to someone who didn't want to hear the caveat, that is stakeholder handling, and it is a real and separately assessed skill in this job.

What does not transfer is the tooling, and there is no way round learning it properly. SQL is not optional; it is the baseline test in almost every technical screen for this role, and "I've used Excel a lot" does not answer a question about joins or window functions. Most job ads will also name at least one of Python, R, Tableau, Power BI, or Looker, and increasingly dbt for anyone working near a modern data warehouse. General comfort with computers does not substitute for having actually written fifty SQL queries against a real dataset with duplicate rows and inconsistent formatting.

Is there a qualification or licence

No. There is no professional body, no protected title, no registration, and nothing resembling a licence to practise, unlike some regulated fields. That is good news in one sense — nobody can lock you out on paper — and bad news in another, because it means the qualifications that do exist (Google Data Analytics Certificate, Microsoft's Power BI certification, IBM's Data Analyst Professional Certificate, CompTIA Data+) carry no legal or licensing weight. They function as a signal that you took the subject seriously enough to finish something, and some recruiters use them as an ATS keyword filter, which is a real if unglamorous reason to hold one. But they do not replace a technical screen, and a hiring manager who has seen a hundred of these certificates on a hundred CVs is not going to treat yours as differentiating on its own. A degree in statistics, economics, or a quantitative science helps at more analytically demanding employers, particularly ones doing causal inference or experimentation work, but it is not required for the bulk of analyst roles that are really about querying, cleaning, and reporting on data that already exists.

What your application has to get past

Three specific obstacles, not general ones. First, keyword filtering: if the advert says SQL, Python, and Tableau, and your CV says "data-driven decision making" without naming the tools, you may not get read by a person at all. Put the actual tool names in, and only the ones you can defend under questioning.

Second, the title problem. If your last three job titles were Marketing Coordinator or Operations Manager, an ATS and a skimming recruiter will read you as unqualified regardless of what you did inside those roles, because the system is matching on title as much as content. The fix is not to lie about the title — it is to put the analytical part of the job in the first third of your CV, described in analyst language: "built weekly reporting dashboards in Power BI covering 40 retail sites" reads as analyst work even under an Operations Manager title, if it's near the top and specific.

Third, and this is the one career changers underestimate: the live technical screen. A take-home exercise or a shared-screen SQL test is now standard at most companies past early-stage startup size, and it is where self-taught skills that look fine on a portfolio project done at your own pace fall apart under fifteen minutes and someone watching. If you have not written SQL against a clock with someone else in the room, you are not ready for this stage yet, no matter how good your portfolio looks.

On the portfolio itself: a project using a clean Kaggle dataset is now assumed and does not distinguish you. What does is a project built on messy, real, or at least realistically messy data — scraped, exported from a real API, or a genuine dataset from your previous field (school attendance records, sales data from your old job if you're allowed to anonymise it, public health or transport open data) — with a write-up that shows the decisions you made about missing values and outliers, not just a finished chart.

How long this actually takes

Be wary of anything promising a fast route. For someone working full-time and studying around it, the realistic range to go from no SQL to passing a junior analyst's technical screen is six to twelve months of consistent, weekly practice — not six weeks of a bootcamp, though a bootcamp can structure that time for you. That estimate covers learning SQL to a level where joins, aggregations, and window functions are comfortable, learning one visualisation tool (Tableau or Power BI) to a level where you can build something a stakeholder would actually use, and building two or three portfolio projects with real data and a written explanation of your reasoning.

After that, expect the job search itself to take longer than it did in your last field, because you are competing against candidates with an analyst title already on their CV, and because the entry-level end of this market is crowded with bootcamp graduates and other career changers doing exactly what you're doing. A move within your current employer — into a reporting or insights role attached to the department you already know — is very often faster than an external hire, because your domain knowledge and internal trust already exist and the employer only has to take a risk on the technical gap, not on you as a person. If that internal route genuinely doesn't exist, treat six months of study plus three to six months of active searching as the honest floor, not the ceiling.

Where this is closed rather than hard: if you cannot get access to any real or realistic dataset to build a portfolio, and you're applying cold to companies with formal, high-volume technical screening (most large tech employers), you will likely be filtered out before anyone reads your reasoning about your old career. That's not a skills problem, it's an access problem, and the practical fix is smaller or less formal employers first, or the internal move, not more certificates.

What to do next

Pick one tool stack (SQL plus Tableau or Power BI, not five things at once) and one real dataset connected to a field you already understand. Build something with it that you can explain query by query. Rewrite your CV so the analytical parts of your current or last job sit in the first third of the page, named in the vocabulary the job ads use, not your own. Then apply to roles where your domain experience is explicitly relevant — a marketer applying to a retail analytics team, a teacher applying to an education-data role — because that is where your old career is an asset instead of something to explain away. jobmarket.pro reads each advert in full and checks it against one profile before an application goes out, which is useful specifically because it will tell you where a domain-knowledge gap or a missing tool is going to sink an application before you send it.