The Blob Storage Black Hole: Why PropTech Migrations Fail at the Attachment Layer

A property management migration can look complete and still be missing the part that matters.

The resident records are there. Unit numbers match. Rent balances reconcile. The dashboard says the portfolio is live.

Then someone opens a resident profile and looks for the signed lease.

Nothing.

Or worse: there is a lease, but nobody can prove it belongs to that resident.

This is the attachment-layer failure that hides behind otherwise successful PropTech migrations. Structured records make the trip because databases are good at exporting rows. The documents attached to those records—leases, move-in inspections, government IDs, notices, addenda, and photos—often arrive as a ZIP file full of generically named objects.

The data moved. The evidence did not.

---

The database moved. The relationship disappeared.

Most property management systems store a resident record and its attachments in different places:

1. The application database holds structured entities such as properties, units, residents, leases, and charges.
2. Blob storage holds the binary files: PDFs, images, scans, and office documents.
3. A pointer connects the two, usually through an attachment table, object key, API identifier, or metadata field.

That third part is the migration.

Copying the database without preserving the object reference produces clean resident rows with no documents. Copying the files without preserving the reference produces thousands of documents with no reliable owner. Both exports can be technically complete while the portfolio is operationally unusable.

Two complete exports can still produce an incomplete migration when the relationship between them is lost.

The failure usually does not announce itself during import. The tenant CSV passes validation. The files exist in the archive. The problem surfaces later, when an implementation specialist has to open documents one by one and decide which resident, lease, or unit each file belongs to.

That is not file transfer. It is manual reconstruction of a relationship the source system already knew.

---

Three ways attachment migrations are handled

Approach	What gets moved	What happens to relationships	Verification	Operational result
Database export only	Structured rows	Attachments are omitted or referenced by dead source-system URLs	Row-level validation only	A clean target database with missing evidence
CSV plus document ZIP	Rows and binary files	Relationships must be inferred from filenames, folders, or a separate lookup sheet	Manual spot checks	A re-attachment queue that grows with every document
Relational attachment migration	Rows, files, metadata, and parent-child links	Every attachment travels with a manifest that identifies its source and target owner	Metadata checks plus document-level verification	Searchable, linked records with an auditable chain of custody

The difference is not whether the files were copied. It is whether every file arrived with enough context to be trusted.

---

Why the attachment layer breaks

Legacy PMS exports rarely fail in one consistent way. The same portfolio can contain several attachment patterns at once:

• A lease stored in S3 with a database object key.
• Inspection photos grouped under a unit folder on a local drive.
• IDs uploaded to a resident profile but named with a random UUID.
• Addenda stored in Dropbox by an implementation team.
• Historical documents exposed through an API that returns temporary download URLs.

A conventional ETL job sees these as unrelated extraction tasks. Pull rows from the database. Download objects from storage. Copy folders from a shared drive.

But a PropTech migration does not need three piles of exported data. It needs one connected record of which document belongs to which entity and why.

Filenames are not enough. A file called document_8823.pdf carries no useful business context. Folder names are not enough either; years of manual uploads and staff turnover make them inconsistent. Even source metadata cannot always be accepted without question, because a document may have been attached to the wrong resident before the migration began.

The migration has to preserve the source relationship and test whether that relationship still makes sense.

---

What a reliable attachment migration preserves

Elvity treats an attachment as a relational record with a file attached—not as an anonymous binary object.

1. Source identity

Before a file moves, the pipeline records where it came from: source system, object key, attachment ID, parent entity, upload timestamp, file type, and available metadata. The file never travels alone.

2. Parent-child context

The extraction creates a manifest that connects the attachment to its source entity. A signed lease may belong to a lease record, which belongs to a resident, which belongs to a unit, which belongs to a property. Preserving only the resident ID can flatten context that the target system needs.

3. Target-system mapping

Source IDs often cannot be reused. The manifest therefore maps the original relationship to the newly created target IDs after properties, units, residents, and leases have been loaded.

4. Content-level verification

Metadata is evidence, not proof. OCR and document analysis can compare names, addresses, unit numbers, effective dates, and document types inside the file against the record it is about to join. A mismatch is flagged for review instead of silently becoming a wrong attachment.

5. Chain of custody

The final record should show where the file originated, which transformations occurred, which target entity received it, and whether a person approved an exception. That lineage matters when the attachment is a signed lease rather than a disposable image.

The manifest is the migration contract: source record, source file, verification result, and target owner stay connected.

---

AI should verify the link, not invent it

Attachment migrations are a useful example of where AI belongs in a production data workflow—and where it does not.

An AI model can read a lease and identify a resident name, property address, unit number, lease term, and document type. That makes it valuable as a secondary verification layer when metadata is incomplete or suspicious.

It should not be allowed to guess silently.

If the source says a lease belongs to Resident A while the document names Resident B, the correct output is not an automatic reassignment. It is a visible conflict with both pieces of evidence attached:

• Source metadata: linked to Resident A
• Document content: names Resident B
• Pipeline action: hold for review

The deterministic relationship remains intact until a person or an approved rule resolves the discrepancy. That is how AI reduces manual work without turning the migration into a black box.

---

The real cost is not storage

Blob storage is cheap. Reconstructing lost context is not.

Once relationships are severed, an implementation team has to reopen files, search for names or addresses, locate the matching resident, and upload the document again. Ambiguous files require customer follow-up. Misattached files create privacy and compliance risk. Missing leases delay operational handoff because the target system cannot become the system of record.

This work scales with the number of attachments, not the number of database rows. A 5,000-unit portfolio can carry tens of thousands of supporting files across current residents, former residents, inspections, notices, and historical leases.

The migration may be technically live while the team is still doing weeks of cleanup.

That is the blob storage black hole: not that files disappear, but that their meaning does.

---

A complete PropTech migration moves the proof

Property, unit, resident, and lease records are only half the operating history of a portfolio. The documents attached to them explain what was signed, inspected, approved, and changed.

A reliable migration therefore has to move four things together:

1. The structured record.
2. The binary attachment.
3. The relationship between them.
4. The lineage that proves how that relationship was preserved.

Elvity’s PropTech data onboarding platform is built around that connected model. It extracts attachments from databases, APIs, object stores, and shared folders; carries parent-child metadata through the pipeline; verifies document content against target records; and preserves an audit trail for every file that lands.

Because a lease sitting in the right bucket is not enough. It has to be attached to the right record, for a reason the next person can verify.