Description:

INTAGLEO SYSTEMS  ·  INTERNAL

Hiring Pack — Data Migration Engineer

For the Vizibly engagement — Yardi SFTP → API migration  ·  Pakistan market  ·  14 September 2026

1. The honest read on this search

Yardi-experienced data engineers do not exist in the Pakistani market in hiring quantity. A search built around that requirement returns either nothing, or CVs listing Yardi because it appeared once in a job spec they worked adjacent to. Running the search that way will cost four weeks and likely produce a bad hire.

Split the requirement. The scarce, hard-to-teach part is migration engineering judgement — batch-to-API semantics, reconciliation discipline, idempotency design, and comfort with SOAP and XML. That is what you hire for. The teachable part is Yardi itself: its data model, its interface quirks, its failure modes. Intagleo already holds that knowledge in-house from a decade of multifamily work and the Denver leasing platform build. That is what you supply. Hire for the first, supply the second, and pair them for the first month.

This also strengthens what you sell Briant. “A dedicated migration engineer backed by our multifamily domain team” is a more credible claim than one person who supposedly has everything — and it survives technical scrutiny on the call, which the other version will not.

Timeline conflict to resolve now. Your earlier email told Briant someone would be working within a couple of weeks. A fresh hire in this market realistically takes four to six weeks to source and another two to ramp. Either staff the first phase from your existing bench and backfill behind it, or reset that expectation on Thursday before it becomes a broken promise. The discovery and parity-mapping phase is well suited to an existing senior person, which buys you the hiring runway.

2. The role, and how it evolves

Vizibly currently moves data between their platform and Yardi over SFTP and is replacing that with an API integration. This person owns that migration end to end, then owns the pipeline that results from it.

Phase 1, roughly months 1–4 — discovery and parity mapping, identity crosswalk design, ingestion rebuild against Yardi web services, historical backfill strategy, parallel-run reconciliation, and phased per-client cutover with rollback.

Phase 2, ongoing — first-line ownership of the pipeline: monitoring, incident response, data quality, and onboarding further client databases. This is the retainer that follows the project, and it is why we hire rather than contract.

3. Scorecard — what to actually filter on

Note where Yardi sits. Putting it in the must-have column is the mistake that stalls this search.

Tier	Requirement	Why
Must have	Has personally migrated a batch or flat-file integration to an API — and seen it through cutover	The exact muscle. Nothing else substitutes.
Must have	Reconciliation discipline: has built diff harnesses, not just pipelines	Parallel run is where this project succeeds or fails.
Must have	Strong SQL and Python; designs idempotent, resumable, incremental loads	Delta feeds remove everything files gave for free.
Must have	Comfortable with SOAP and XML, not only REST and JSON	Yardi web services are SOAP. Many strong engineers have never touched it.
Strong signal	Worked against a third-party API they did not control and could not change	Teaches the right instincts about throttling, gaps and vendor escalation.
Strong signal	Multi-tenant credential handling across many client environments	Every Yardi client database is its own licence and credential set.
Strong signal	Has owned a production cutover with a rollback plan	Migration is a finishing skill, not a starting one.
Teachable	Yardi Voyager, RentCafe, the multifamily data model	Supply from your bench. Do not screen on it.
Teachable	dbt, Airflow, the specific warehouse	Weeks, not months, for a strong engineer.

4. Where to find them in Pakistan

Adjacent domains — the highest-yield route

The batch-to-API migration is not unique to property management. Several industries with a large Pakistani delivery presence are running structurally identical projects right now, and their engineers transfer almost directly:

• US healthcare integration — HL7 v2 to FHIR, and X12 EDI 837/835 claims. The closest analog there is: flat-file batch to API, with identity crosswalks, enum mapping and reconciliation. Pakistan has a deep RCM and health-integration industry. Start here.
• Payments and fintech — SWIFT MT to ISO 20022 migration is happening industry-wide, and ISO 8583 work carries the same instincts about idempotency and duplicate prevention.
• Logistics and supply chain — X12 and EDIFACT EDI, where partners are moving to APIs on their own timelines.
• Insurance claims — batch file exchange with carriers, same migration pressure.

Channels

• LinkedIn Recruiter with the strings below — primary channel for this seniority.
• Rozee.pk and Mustakbil for volume, though expect lower signal at this level.
• Referrals from your multifamily platform team — engineers who have worked on US integration projects know others who have.
• Targeted approach to integration-heavy software houses in Lahore, Karachi and Islamabad serving US healthcare and fintech clients.
• Alumni networks — FAST, NUST, LUMS, UET, GIKI — filtered by employer rather than by year.

Search strings

Run the domain-adjacent string first. It will outperform the Yardi string by a wide margin.

("data engineer" OR "integration engineer" OR "ETL developer") AND ("HL7" OR "FHIR"

OR "X12" OR "EDI" OR "ISO 20022" OR "ISO 8583") AND ("migration" OR "integration")

 

("data engineer" OR "integration engineer") AND ("SFTP" OR "flat file" OR "batch")

AND ("REST API" OR "SOAP" OR "web services") AND ("reconciliation" OR "cutover")

 

("Yardi" OR "RealPage" OR "Entrata" OR "multifamily" OR "property management system")

Low yield, but costs nothing to run and an occasional match is worth a lot.

5. CV screening

Green flags

• Describes a cutover, not just a build — phased rollout, parallel run, rollback plan.
• Mentions finding a bug in the old system during reconciliation. This is the strongest single signal on a CV; it means they actually did the comparison work rather than assuming the legacy path was correct.
• Talks about data in terms of semantics — deletes, nulls, identity, late-arriving records — rather than a list of tools.
• Has dealt with a vendor API they could not change, and says what they did about its gaps.
• Stayed long enough on at least one project to see it reach production.

Red flags

• Yardi, RealPage or Entrata sitting in a skills blob with no project context. Ask immediately what they actually built against it; the answer usually ends the conversation.
• Only REST and JSON, and dismissive when SOAP comes up. The dismissiveness matters more than the gap.
• ETL described purely as tool operation — SSIS, Informatica or Talend drag-and-drop — with no code anywhere.
• Pipelines only ever described as “built”. No mention of incidents, backfills, data quality or anything breaking.
• dbt and Airflow listed prominently but SQL depth collapses under a single follow-up question.
• A pattern of leaving projects before cutover.

6. Interview kit

Six questions, roughly 45 minutes. They are ordered so that Q1 alone separates most candidates — if it goes badly, stop.

Q1.  You are replacing a nightly full-snapshot CSV with an API that returns records modified since a timestamp. What breaks?

Strong answer — Goes straight to deletions: a full snapshot tells you what disappeared, a delta feed does not, so deleted records live forever downstream. Adds that you need a periodic full-reconcile sweep to catch it, and asks whether the vendor stamps modification dates on backdated changes — because if not, retroactive edits are invisible too.

Weak answer — Talks only about pagination and rate limits. Both real, both secondary, and neither loses data silently.

Q2.  Your sync dies at page 400 of 900. What happens on restart?

Strong answer — Durable cursor or watermark persisted per entity, upsert rather than insert semantics, and an idempotency strategy so replaying overlapping pages is harmless. Mentions being able to rewind the watermark deliberately for a backfill.

Weak answer — “We re-run the job.” Tells you they have never had a half-successful sync, which files never gave them.

Q3.  Old and new pipelines are running in parallel. 0.3% of lease records disagree. What do you do?

Strong answer — Categorises before fixing — timing, genuine API gap, transformation bug, or a bug in the old pipeline. The tell is whether they consider that the legacy path might be wrong. Describes an automated field-level diff with tolerance rules rather than eyeballing samples.

Weak answer — Immediately sets about making the new pipeline match the old one. That is how you faithfully reproduce an existing bug.

Q4.  Files were keyed on a human-readable property code. The API returns an internal system ID. How do you keep five years of history joinable?

Strong answer — A versioned crosswalk table as a first-class artifact, populated and validated during parallel run. Raises reuse and collision — the same property code recycled across environments or after an acquisition — and what happens when the mapping is not one-to-one.

Weak answer — Treats it as a simple rename or a join added at query time.

Q5.  The API rate-limits well below what a three-year historical backfill needs. What now?

Strong answer — Treats the cutover seam as a deliberate design decision: keep legacy-derived history, start API data at a defined boundary, and make the seam explicit to downstream consumers. Weighs it against a slow throttled backfill rather than assuming one answer.

Weak answer — Proposes brute-forcing the backfill, or has no view on what happens to history at all.

Q6.  Vendor documentation says a field exists. Production returns null for it. What do you do?

Strong answer — Reproduces it, builds a minimal case, escalates with evidence, and designs a fallback while waiting rather than blocking. This question is really about whether they will push back on Yardi and a client’s own consultants.

Weak answer — Waits for the vendor, or quietly works around it without telling anyone the field is unreliable.

7. Take-home exercise

Optional, and only for candidates who clear the interview. Two to three hours, and tell them to timebox it.

Give them a messy sample CSV in the shape of a nightly property export — mixed date formats, sentinel nulls, a duplicate key, one record silently dropped versus the prior day — together with a one-page mock spec for a delta API that supersedes it.

Ask for a written migration and reconciliation plan, not code. What you are grading:

• Did they notice the dropped record, and do they say how the API would fail to reveal it?
• Did they identify the duplicate key and propose an identity strategy?
• Do they define what “reconciled” means numerically before proposing a cutover?
• Do they ask questions about the spec rather than assuming it is complete?

That last one matters most. The spec is deliberately incomplete.

8. Running the search

Week	Action	Target
Week 1	Run the adjacent-domain strings, open outreach to healthcare and fintech integration engineers, brief your referral network	40–60 approaches
Week 2	CV screen against section 5, phone screen for Q1 and Q4 only	8–12 phone screens
Week 3	Full interview kit with a senior engineer from the multifamily team present	4–5 full interviews
Week 4	Take-home for finalists, reference calls focused on whether they finished what they started	2 offers out

Hold the domain pairing plan ready from day one. Whoever you hire needs a named person from the multifamily team available for their first month, and that should be agreed before the offer goes out rather than improvised after.

9. Post copy

Short enough for LinkedIn and job boards. Deliberately leads with the problem rather than a stack list — the engineers worth having respond to the problem.

Data Migration Engineer — Integrations

We are looking for an engineer who has moved a real integration off flat files and onto an API, and stayed with it through cutover.

Our client runs a property technology platform that exchanges data with Yardi over SFTP today. That is being replaced with an API integration. You would own it: mapping what the files actually carry against what the API actually returns, designing the identity crosswalk so five years of history stays joinable, rebuilding ingestion around delta semantics, running the old and new pipelines side by side until the numbers agree, and cutting clients over in phases with a rollback plan that works.

You do not need property management experience. We have a decade of it in-house and will pair you with it. What we cannot teach quickly is the migration judgement — knowing that a delta feed hides deletions, that a half-finished sync is a different problem from a failed one, and that when reconciliation disagrees the old pipeline is sometimes the one that is wrong.

Strong SQL and Python. Comfortable with SOAP and XML, not just REST and JSON. Experience with HL7/FHIR, X12 EDI, ISO 20022 or similar batch-to-API migrations transfers directly and we would like to hear about it.

Based in [city], [hybrid/remote]. Migration project first, ongoing platform ownership after.

Internal document — not for circulation outside Intagleo.  ·  arslan@intagleo.com

Apply to Position