Real estate property data import fails due to duplicate property IDs in legacy system

We’re migrating property data from our legacy real estate management system to Oracle Fusion Cloud Real Estate Management (23C) using a combination of FBDI and custom ETL scripts. The import process fails consistently due to duplicate property IDs that exist in our legacy data.

Error message:


Duplicate Property ID 'PROP-12345' found
Property record already exists for this identifier

Our legacy system allowed duplicate property IDs in certain scenarios - specifically when properties were subdivided or merged. We have approximately 3,200 properties in our portfolio, with about 180 having duplicate IDs across different time periods or organizational units. The legacy data profiling shows these duplicates have different addresses, lease terms, and ownership structures.

We need a strategy to deduplicate and create unique identifiers for Oracle while maintaining the ability to trace back to legacy property records. Has anyone dealt with duplicate property ID scenarios during real estate data migration?

That’s a great point about ongoing integrations. We do have a facility management system that will continue sending work orders referencing legacy property IDs. So we definitely need a persistent mapping solution. Should this mapping table be in Oracle or in our middleware layer?

Here’s a comprehensive solution addressing all three critical aspects of your property data migration:

1. Legacy Data Profiling & Analysis:

First, complete a thorough profiling of your 180 duplicate records. Create a classification framework:

-- Profiling query to categorize duplicates
SELECT
  legacy_property_id,
  COUNT(*) as occurrence_count,
  COUNT(DISTINCT address) as unique_addresses,
  COUNT(DISTINCT org_unit) as unique_orgs,
  MIN(create_date) as first_occurrence,
  MAX(create_date) as last_occurrence,
  CASE
    WHEN COUNT(DISTINCT address) = 1
      THEN 'DATA_ENTRY_ERROR'
    WHEN subdivision_flag = 'Y'
      THEN 'SUBDIVISION'
    ELSE 'REGIONAL_DUPLICATE'
  END as duplicate_type
FROM legacy_properties
GROUP BY legacy_property_id
HAVING COUNT(*) > 1

Document each duplicate scenario with:

  • Business reason for duplicate
  • Which record should be the primary in Oracle
  • Whether historical records need preservation
  • Dependencies in other systems

2. Deduplication Strategy by Scenario:

Scenario A: Data Entry Errors (42 cases)

  • Action: Consolidate into single Oracle property record
  • ID Strategy: Keep most recent legacy ID or the one with most complete data
  • Data Handling: Merge attributes, taking most recent or most complete values

ETL Logic:

SELECT
  legacy_id,
  COALESCE(r1.property_name, r2.property_name) as name,
  COALESCE(r1.address, r2.address) as address,
  GREATEST(r1.last_update, r2.last_update) as source_date
FROM
  (SELECT * FROM legacy WHERE id = 'PROP-X'
   ORDER BY last_update DESC LIMIT 1) r1

Scenario B: Subdivisions (65 cases)

  • Action: Create unique Oracle property records for each subdivision
  • ID Strategy: Generate new sequential IDs with parent reference
  • Mapping: PROP-12345 becomes PROP-12345-A, PROP-12345-B, etc.

ID Generation:


Original: PROP-12345
Oracle IDs:
  PROP-12345-01 (Unit A)
  PROP-12345-02 (Unit B)
  PROP-12345-03 (Unit C)

Store parent property ID in DFF for relationship tracking.

Scenario C: Regional Duplicates (35 cases)

  • Action: Append region/org identifier to create unique IDs
  • ID Strategy: {Legacy_ID}-{Region_Code}
  • Example: PROP-12345 in East region becomes PROP-12345-EAST

Mapping Table Structure:

CREATE TABLE property_id_mapping (
  legacy_property_id VARCHAR2(50),
  oracle_property_id VARCHAR2(50),
  region_code VARCHAR2(10),
  duplicate_scenario VARCHAR2(30),
  effective_start_date DATE,
  effective_end_date DATE,
  is_primary_record VARCHAR2(1),
  migration_notes VARCHAR2(500)
);

Scenario D: Merge/Re-split (38 cases)

  • Action: Create time-based property records with effective dating
  • ID Strategy: Use current state IDs, document history in notes
  • Relationship: Link related properties through custom attributes

3. ID Mapping Implementation:

Create Persistent Mapping Solution:

Store mapping table in Oracle as a custom table accessible to all integrations:

CREATE TABLE XXRE_PROPERTY_ID_XREF (
  xref_id NUMBER PRIMARY KEY,
  legacy_system_code VARCHAR2(10),
  legacy_property_id VARCHAR2(50),
  oracle_property_number VARCHAR2(50),
  property_name VARCHAR2(240),
  region_code VARCHAR2(10),
  mapping_type VARCHAR2(30),
  active_flag VARCHAR2(1),
  created_by VARCHAR2(100),
  creation_date DATE,
  last_updated_by VARCHAR2(100),
  last_update_date DATE
);

CREATE INDEX idx_legacy_prop
  ON XXRE_PROPERTY_ID_XREF(legacy_property_id);
CREATE INDEX idx_oracle_prop
  ON XXRE_PROPERTY_ID_XREF(oracle_property_number);

Build Integration Translation Layer:

For systems sending work orders or transactions with legacy IDs:

-- Translation function for incoming interfaces
CREATE OR REPLACE FUNCTION get_oracle_property_id(
  p_legacy_id VARCHAR2,
  p_region VARCHAR2 DEFAULT NULL
) RETURN VARCHAR2 IS
  v_oracle_id VARCHAR2(50);
BEGIN
  SELECT oracle_property_number
  INTO v_oracle_id
  FROM XXRE_PROPERTY_ID_XREF
  WHERE legacy_property_id = p_legacy_id
    AND active_flag = 'Y'
    AND (region_code = p_region OR p_region IS NULL)
    AND ROWNUM = 1;

  RETURN v_oracle_id;
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    RETURN NULL;
END;

Configure DFF for Legacy Reference:

In Oracle Real Estate Property setup:

  • Navigate to: Setup and Maintenance > Manage Descriptive Flexfields
  • Add custom segment: LEGACY_PROPERTY_ID
  • Make it required and displayed on property forms
  • Use this field in all reports requiring legacy reference

Migration Execution Plan:

  1. Pre-Migration (Week 1-2):

    • Complete duplicate analysis and classification
    • Create and populate mapping table with proposed new IDs
    • Review with business stakeholders for approval
    • Document all ID mapping decisions
  2. Data Transformation (Week 3):

    • Apply deduplication rules in ETL
    • Generate unique Oracle property IDs
    • Populate mapping table with final assignments
    • Transform FBDI files with new IDs
  3. Migration (Week 4):

    • Load property master data via FBDI
    • Validate all properties imported successfully
    • Verify no duplicate ID errors
    • Run reconciliation reports
  4. Post-Migration (Week 5):

    • Deploy translation functions to integration middleware
    • Update interface mappings to use crossref table
    • Test work order submissions from facility system
    • Monitor for any ID resolution issues

Validation Queries:

After migration, verify data quality:

-- Check for any remaining duplicates
SELECT property_number, COUNT(*)
FROM pjf_properties_vl
GROUP BY property_number
HAVING COUNT(*) > 1;

-- Verify mapping coverage
SELECT
  COUNT(DISTINCT legacy_property_id) as legacy_count,
  COUNT(DISTINCT oracle_property_number) as oracle_count
FROM XXRE_PROPERTY_ID_XREF;

This comprehensive approach ensures clean property data in Oracle while maintaining traceability to legacy systems and supporting ongoing integrations that reference old property identifiers.

Good point about analyzing the duplicates by scenario. I reviewed our 180 cases: 65 are subdivisions where one property was split into multiple units, 42 are data entry errors where the same property was entered twice with slight variations, 38 are properties that were merged then re-split over time, and 35 are actually different properties in different regions that mistakenly got assigned the same ID. How should I approach the ID mapping for each scenario?

Make sure your ID mapping strategy accounts for future data loads and integrations. If you have ongoing interfaces from other systems that reference the legacy property IDs, you’ll need a persistent mapping table that remains accessible. Consider creating a custom lookup or reference table in Oracle that stores the legacy-to-Oracle ID mappings. This becomes critical for things like lease management, facility maintenance requests, or financial transactions that might still reference old property IDs from integrated systems.

I’ve handled similar situations in property migrations. Your deduplication strategy should address the root cause - why do duplicates exist? If properties were subdivided, they should have parent-child relationships in Oracle. If they represent different lease periods for the same physical property, you need to model them as single properties with multiple lease records. Before creating new IDs, analyze the 180 duplicates to understand the business scenarios. Group them by reason: subdivisions, mergers, data entry errors, or legitimate separate properties that happened to get the same ID. Each scenario needs a different handling approach in Oracle’s data model.

For each scenario, use a different approach: Data entry errors should be consolidated into single records with the correct information. For subdivisions, create unique IDs for each sub-property and establish parent-child relationships if Oracle Real Estate supports that hierarchy. For merge/re-split scenarios, create separate property records for each current state and use effective dating to show the history. For mistaken duplicate IDs across regions, append region codes to create unique identifiers. In all cases, store the original legacy ID in a custom attribute so you can always trace back. Your ETL process should include a deduplication rules engine that applies the appropriate strategy based on the duplicate scenario.

Oracle Fusion requires unique property identifiers - duplicates aren’t allowed. You’ll need to generate new unique IDs for Oracle while keeping your legacy IDs as reference fields. Create a mapping table that stores both the original legacy ID and the new Oracle-generated ID. You can use Oracle’s Property Number field for the new unique ID and store your legacy ID in a DFF (Descriptive Flexfield) for reference.