Data conversion specialist: every seat on a policy conversion

A data conversion specialist moves data out of an old system, reshapes it for a new one and proves it arrived intact. On an insurance policy conversion, where an insurer moves its in-force book off a legacy policy administration system, the title usually covers four different jobs: owning the field and code map, reading the scanned forms the map cannot see, owning the renewal offer each converted customer will receive, and signing the wave. The work is hard because a policy is not a row: its rating sits partly in fields, partly in free-text remarks and partly on paper. Botminds' Policy Data Conversion exists for that gap. Its agents read the legacy data and the scanned forms, re-rate every policy in the new system and trace each difference to its cause, so the people in the four seats spend their time deciding rather than hunting.

The cost of one person holding all four seats is not overtime. It is that nobody owns the boundary between them: the alarm credit that sat in a remark, the jewelry schedule that existed only on a scan, the renewal that would have gone out $14 higher with no explanation. Those are the errors a customer finds first.

What does a data conversion specialist do on an insurance conversion?

On a policy conversion the specialist turns each in-force policy into the same policy on a new system, then proves it. That breaks into a fixed sequence: profile the legacy extracts, map products, forms, fields and code values, load a test batch, re-rate it, compare it with the legacy premium and coverage, trace every difference to its cause, fix the map and load again. Each pass is one convert, load and compare cycle, and a book is usually converted in waves, each wave going through several cycles before anyone signs it.

Generic job descriptions stop at the first half: extract, transform, load. In insurance the second half is the job, because state examiners test the result, not the load: their market conduct standards check that the premium charged follows the filed rates and that each policy was issued or renewed accurately. A conversion that loads every row and changes one rating input on a few hundred policies passes a row count and fails that test.

Take a sample conversion, on fictional people and companies, as it runs through Botminds' Policy Data Conversion. Larkhaven Mutual is moving 214,860 in-force policies off HOMER, an in-house mainframe in service since 1994, one wave of renewals at a time. Wave 3 is 18,412 homeowners policies in Iowa and Nebraska. At test load 3, 17,596 matched to the cent, 309 were within the $1.00 rounding tolerance, 472 differed and 35 could not be converted. Every one of those 472 needed a person to decide something, and the decisions belong to different people.

Four jobs hide inside one title

The four seats are the map, the forms, the offer and the signature. They need different knowledge, they fail in different ways and, in a well-run programme, they are signed by different people. A bank regulator's guidance on system conversions makes the same point in general terms: the conversion team "should include stakeholders with knowledge of the interdependencies of the system being converted" (FFIEC IT Examination Handbook, 2024, written for banks, but the problem is the same).

Interdependency is exactly what a single specialist cannot hold. The person who knows that HOMER's protective device field only says Y is a mapping expert. The person who knows the alarm type lives in a remark and on a certificate from 2019 is a forms and rating expert. The person who knows that a $14 rise will reach the customer as an unexplained renewal increase works in policy services. Put all three in one head and the boundary errors vanish from view until the renewal mails.

The map owner: fields, codes and the values with no target

The map owner decides how every legacy product, form, field and code value lands in the new system. In the sample conversion the map at version 3.8 covers 9 products, 64 forms, 212 fields and 1,318 code values. Most are mechanical: construction code F becomes Frame, endorsement code WBU10 becomes water backup at $10,000. The seat earns its keep on the rest.

The dangerous values are the ones with no clean target. HOMER stored a roof age class, not a year; the new system needs a year and, left alone, falls back to the year the house was built. It stored the wind and hail deductible in dollars; the new system wants a percentage and rounds. A code that once meant one territory now splits into two. None of these raises a load error. Each changes a premium. The map owner's real deliverable is a list of every value that was not mapped cleanly, with a decision and a name against each one.

The map owner's view: every code value, with the doubtful ones named

The forms reader: the seat most plans leave empty

The forms reader decides what the scanned documents say when the fields do not. Legacy systems kept half their rating outside fields: in remarks typed by underwriters and on paper that was scanned and attached. A field map cannot see either. In the sample wave, the alarm type behind a protective device credit sat in the remarkCS ALM SOUTHGATE MON #77412 CERT REC 03/19 and on a scanned certificate of alarm installation; a jewelry schedule on form HO 04 61 existed only as a scan, so the extract carried its premium but not its items.

That makes the seat unavoidable whenever the basis for a premium is on paper. Someone has to read the scan before the policy can be converted, and someone has to say which reading stands when a page is unclear, a decision that needs a person who knows the forms: which edition of an endorsement was attached, what an inspector's roof note means for the rating, whether an appraisal still supports a scheduled item. In the sample wave the agents read 41,206 scanned documents and sent 12 they could not read to a person.

The renewal-offer owner: where the conversion meets the customer

Policy services owns the moment a converted policy first reaches the customer, which is usually its renewal offer. If a conversion error changes the premium or the coverage, that offer is where it surfaces, and state law has already fixed when the offer must leave. Iowa, for instance, has required a personal lines renewal policy, offer to renew or notice of nonrenewal at least 60 days before the end of the term since January 2025, with the information also sent to the producer of record (Iowa Code §515.129C).

So this seat sets a hard date for everyone else, and it owns the policies the agents cannot convert. In the sample wave 35 policies stayed on the legacy system: 21 with no construction type, 9 whose ZIP did not match the county, and 5 where the named insured had died and the estate was pending. Each needs an action with an owner: request the data from the agent, correct the address, or convert by hand at renewal. When a conversion also moves policies onto new forms with material changes, Texas adds a notice to the insurer's agents at least 30 days before the first renewal on the new form (Tex. Ins. Code §551.1055), another date this seat must hold.

The renewal-offer owner's queue: 35 policies that need a person

Who manages data migration on a policy conversion?

The programme manager manages it, and the insurer stays accountable for it even when a vendor does the work. On a policy conversion the programme manager holds the plan, the waves and the last signature; the conversion lead and the policy services lead sign before them. Many insurers hire the policy system vendor or a systems integrator to run the conversion, which moves the labour but not the duty.

State examiners check that the insurer keeps watch over anyone doing its work under contract (NAIC exam standards). The NAIC's Insurance Data Security Model Law, the template for state data security laws, requires an insurer to choose such vendors with due diligence and to require them to protect the information they hold (NAIC Model Law #668, §4.F; the oversight both rules imply is set out in insurance back office outsourcing companies). A conversion vendor holds the whole in-force book, with names, addresses and claims history, for months.

Data conversion analyst or data migration specialist: what the job titles mean

The titles overlap, but in job advertisements they lean in different directions. A data conversion analyst is usually closest to the business: profiling legacy data, writing the mapping specification, reconciling results and explaining differences. A data migration specialist or engineer usually builds the extract and load: scripts, staging databases, performance, cut-over runbooks. In insurance, the analyst role also needs to read a rating manual and a declarations page, because the test of the work is whether a policy rates the same afterwards.

Neither title names the forms reader or the renewal-offer owner, which is why those seats so often go unstaffed. When you read or write a job description for a conversion, check which of the four seats it actually covers, and who covers the others.

Where a convert, load and compare cycle's days go

Most of a by-hand cycle goes on finding and explaining differences, not on moving data. Botminds' estimate for one cycle on one wave, done by hand, is 22 working days: four on profiling and mapping, three on loading and re-rating, five on reconciling premium and coverage, five on tracing each difference to its cause, three on fixing the map and reloading, and two on the sign-off report. Ten of the 22 are reconciling and tracing.

That split is the case for separating the seats. The days spent tracing are days in which the person who should be deciding a mapping is instead searching a remark field, and the person who should be preparing renewal offers is waiting for a list of affected policies. The reconciliation report example shows what those ten days are trying to produce, and why batch totals cannot produce it.

What does a data migration specialist earn?

There is no government pay series for "data conversion specialist", so the closest benchmark is the database occupations. The Bureau of Labor Statistics put the median annual wage of database administrators at $104,620 and of database architects at $139,500 in May 2025. In finance and insurance the medians were higher: $123,280 for administrators and $146,470 for architects (BLS Occupational Outlook Handbook). Finance and insurance employed 12% of database administrators and 15% of database architects.

Legacy skills add a premium of their own. Reviewing the federal government's oldest systems, GAO found agencies "have had difficulty finding employees with such knowledge and may have to pay a premium for specialized staff or contractors", because COBOL and assembly language have "a dwindling number of people available with the skills needed to support them" (GAO-25-107795). Those are federal systems, not insurers', but an insurer whose policy system was written in the same languages will recognise the market.

How Botminds' Policy Data Conversion changes each seat

The solution does not merge the seats; it gives each one its own queue and takes the reading away from all of them. Six agents read the legacy extracts and scanned documents, map with a stated confidence, convert and re-rate every policy at the legacy rate version, group differences by cause, draft one rule per cause and tie out each wave. People approve every rule, decide every doubtful mapping and sign the wave in order.

In the sample wave that turned one cause, a protective device credit dropped because the map had no target for a bare Y, into one decision. The evidence across all 128 affected policies was on one screen: 128 of 128 remarks named a central station, and 119 alarm certificates and 9 monitoring invoices showed fire and burglary monitoring. The conversion lead approved the rule, the map moved to version 3.8, and all 128 policies re-rated to the cent. How the agents decide when to ask rather than guess is set out in what an insurance data migration tool should do.

The data migration plan template puts these seats into a plan, wave by wave, with the date each one has to finish.

Questions people ask

What is a data conversion specialist?

A data conversion specialist moves data from one system to another, reshaping it to fit the new system and proving it arrived complete and accurate. On an insurance policy conversion that means turning each in-force policy into the same policy on a new system and showing it rates the same, which is why the role usually needs rating and forms knowledge as well as technical skill.

Where do data conversion jobs sit in an insurance company?

They sit in three places: in the IT or programme office that runs a system replacement, in the policy system vendor or systems integrator hired to convert, and in the business teams that own products and policy services. BLS data put 12% of database administrators and 15% of database architects in finance and insurance in 2025.

Do data migration jobs in insurance need COBOL?

Often, if the legacy system is a mainframe. You need someone who can read the old record layouts and code tables, even if others produce the extract. In its 2025 review of the federal government's oldest systems, GAO reported agencies paying a premium for staff and contractors with COBOL and assembly skills; an insurer on the same languages faces the same market.

Can the conversion be handed to the policy system vendor?

The work can; the accountability cannot. Market conduct examiners check that an insurer adequately monitors any entity acting on its behalf, and the NAIC's data security model law calls for due diligence in choosing a third-party service provider that holds policyholder data. Keep the sign-off seats inside the insurer.

What does a data conversion analyst hand over at the end of a wave?

A signed reconciliation: policy count, written premium and every coverage tied out between the old and new systems, each difference explained by cause, each fix as a versioned rule with who approved it, and a list of policies that could not convert with an owner and action for each. In the sample wave that list was 35 policies long.