{"id":894,"date":"2026-09-23T16:55:22","date_gmt":"2026-09-23T13:55:22","guid":{"rendered":"https:\/\/archer.solutions\/?p=894"},"modified":"2026-10-28T17:02:59","modified_gmt":"2026-10-28T14:02:59","slug":"real-estate-erp-data-migration","status":"publish","type":"post","link":"https:\/\/archer.solutions\/ar\/2026\/09\/23\/real-estate-erp-data-migration\/","title":{"rendered":"How to Migrate Years of Real Estate Contracts, Payments, and Customer History"},"content":{"rendered":"<p>Real estate ERP data migration often begins only after a developer has operated for years on its core system. During that time, projects, buildings, units, reservations, contracts, amendments, payment schedules, receipts, cheques, broker records, customer statements, service requests, and accounting entries accumulate across software, spreadsheets, local databases, and paper files.<\/p>\n<p>The migration question is therefore not simply, \u201cCan we import the old records?\u201d The real question is whether the new environment can continue to explain each customer obligation and financial balance after the old system is retired. A successful migration makes that history usable. An unsuccessful one may preserve thousands of records while breaking the relationships people need to run the business.<\/p>\n<p>For the wider operating context, see Archer Solutions\u2019 <a href=\"https:\/\/archer.solutions\/ar\/%d8%a7%d9%84%d9%82%d8%b7%d8%a7%d8%b9%d8%a7%d8%aa\/%d9%86%d8%b8%d8%a7%d9%85-%d8%aa%d8%ae%d8%b7%d9%8a%d8%b7-%d9%85%d9%88%d8%a7%d8%b1%d8%af-%d8%a7%d9%84%d9%85%d8%a4%d8%b3%d8%b3%d8%a7%d8%aa-erp-%d9%84%d9%84%d8%b9%d9%82%d8%a7%d8%b1%d8%a7%d8%aa\/\">Real Estate ERP approach for property developers<\/a>. This guide focuses specifically on historical data migration rather than the complete ERP scope.<\/p>\n<nav aria-label=\"Article contents\" style=\"margin:28px 0 34px;padding:22px 24px;border:1px solid #d9d4e3;border-radius:12px;background:#faf8fc;\">\n<p style=\"margin:0 0 12px;color:#25133f;\"><strong>In this guide<\/strong><\/p>\n<ul style=\"margin:0;padding-left:22px;line-height:1.7;\">\n<li><a href=\"#migration-routes\">Choose the right migration route<\/a><\/li>\n<li><a href=\"#why-real-estate-migration-is-difficult\">Understand why real estate data is difficult<\/a><\/li>\n<li><a href=\"#migration-scope\">Define the migration scope<\/a><\/li>\n<li><a href=\"#migration-method\">Follow the six-stage migration method<\/a><\/li>\n<li><a href=\"#migration-validation\">Validate the migrated data<\/a><\/li>\n<li><a href=\"#published-evidence\">Review published delivery evidence<\/a><\/li>\n<li><a href=\"#buyer-questions\">Ask the right approval questions<\/a><\/li>\n<\/ul>\n<\/nav>\n<h2 id=\"migration-routes\">Which migration route does the project require?<\/h2>\n<p>Three different activities are often described as \u201cmigration,\u201d but they require different controls:<\/p>\n<ul>\n<li><strong>Native version upgrade:<\/strong> converting an existing Odoo database from an older release to a newer supported release. Odoo recommends testing an upgraded database before production and notes that custom modules must be compatible with the target version. <a href=\"https:\/\/www.odoo.com\/documentation\/18.0\/administration\/upgrade.html\" target=\"_blank\" rel=\"noopener\">Review Odoo\u2019s official database-upgrade guidance<\/a>.<\/li>\n<li><strong>Structured import:<\/strong> loading a bounded, sufficiently clean dataset through standard import tools. Odoo\u2019s guidance highlights the importance of stable External IDs when imported records may later be updated. <a href=\"https:\/\/www.odoo.com\/documentation\/18.0\/applications\/essentials\/export_import_data.html\" target=\"_blank\" rel=\"noopener\">See Odoo\u2019s official import documentation<\/a>.<\/li>\n<li><strong>Business-semantic migration:<\/strong> reconstructing customers, contracts, installments, payments, accounting, and operational relationships when sources are incomplete, inconsistent, or originate in another system.<\/li>\n<\/ul>\n<p>The correct real estate ERP data migration route depends on source condition, version gap, customizations, business scope, and the evidence required for acceptance. A native upgrade may be one technical component, but it does not replace the work needed to reconcile business meaning.<\/p>\n<h2 id=\"why-real-estate-migration-is-difficult\">Why is real estate ERP data migration unusually difficult?<\/h2>\n<p>Real estate transactions create long-lived obligations. A unit may be reserved, contracted, rescheduled, transferred, cancelled, refunded, or handed over across several years. Its customer account may contain installments, partial payments, cheque replacements, late changes, credit balances, and accounting entries created under different operating practices.<\/p>\n<p>Those records are not independent. A payment is meaningful because it is allocated to an obligation. An installment is meaningful because it belongs to a valid contract. A contract is meaningful because it links the correct customer to the correct unit, company, project, price, and approved terms. If one link is lost, a technically successful import can still produce an unusable customer statement.<\/p>\n<p>In installment-led real estate businesses, migration becomes more demanding when several legal companies and projects share long payment schedules, post-dated instruments, rescheduling, brokerage, After Sales, and Handover. The mix differs by market and business model, but the validation requirement is universal: every financial and operational relationship must remain explainable after migration.<\/p>\n<h3>Legacy sources describe the same business in different ways<\/h3>\n<p>Older systems may use internal codes that no longer match current project or customer names. Spreadsheets may contain manual adjustments that were never written back to the source application. Paper documents may be the only evidence of an amendment. Accounting systems may summarize balances differently from the commercial system.<\/p>\n<p>Migration must reconcile these meanings. Copying a column named \u201ccustomer\u201d into another field named \u201ccustomer\u201d is not enough when duplicates, inactive records, shared family names, company boundaries, and changed identifiers are present.<\/p>\n<h3>Historical inconsistency becomes a current operating risk<\/h3>\n<p>A mismatch that was tolerated in a spreadsheet becomes more visible once an ERP generates customer statements, collection forecasts, journal entries, approvals, and follow-up activities from the same data. Migration is the point at which the organization must decide which source is authoritative, how exceptions will be treated, and which historical differences require business approval.<\/p>\n<h2 id=\"migration-scope\">What should be included in the migration scope?<\/h2>\n<p>The first migration workshop should define the business decisions the new system must support on day one. For most sales-led real estate environments, the governed core is the commercial-to-financial chain. Construction, procurement, and project-cost history may also be relevant for developer-led organizations, but they should be included only when they are part of the confirmed ERP scope.<\/p>\n<div style=\"margin:28px 0 32px;overflow-x:auto;-webkit-overflow-scrolling:touch;border:1px solid #d9d4e3;border-radius:12px;\">\n<table style=\"width:100%;min-width:820px;border-collapse:separate;border-spacing:0;background:#ffffff;\">\n<thead>\n<tr>\n<th scope=\"col\" style=\"width:29%;padding:16px 18px;text-align:left;vertical-align:top;line-height:1.35;color:#25133f;background:#f4f0fa;border-right:1px solid #d9d4e3;\">Data group<\/th>\n<th scope=\"col\" style=\"width:37%;padding:16px 18px;text-align:left;vertical-align:top;line-height:1.35;color:#25133f;background:#f4f0fa;border-right:1px solid #d9d4e3;\">Relationships that must survive<\/th>\n<th scope=\"col\" style=\"width:34%;padding:16px 18px;text-align:left;vertical-align:top;line-height:1.35;color:#25133f;background:#f4f0fa;\">Typical validation question<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;border-right:1px solid #e4e0e9;\"><strong>Property structure<\/strong><br \/>Companies, projects, phases, buildings, and units<\/td>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;border-right:1px solid #e4e0e9;\">Ownership, hierarchy, availability, status, and analytic dimensions<\/td>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;\">Does every migrated unit belong to the correct legal and project structure?<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;border-right:1px solid #e4e0e9;\"><strong>Customer and contract<\/strong><br \/>Customers, reservations, contracts, and amendments<\/td>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;border-right:1px solid #e4e0e9;\">Customer identity, unit, price, dates, terms, status, and transfer history<\/td>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;\">Can the system explain the active agreement and its approved changes?<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;border-right:1px solid #e4e0e9;\"><strong>Installments and collections<\/strong><br \/>Schedules, receipts, payments, cheques, and allocations<\/td>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;border-right:1px solid #e4e0e9;\">Obligation, due date, paid amount, allocation, replacement, and outstanding balance<\/td>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;\">Does the customer statement reconcile to the approved commercial history?<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;border-right:1px solid #e4e0e9;\"><strong>Finance<\/strong><br \/>Invoices, journal entries, banks, and reconciliations<\/td>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;border-right:1px solid #e4e0e9;\">Company, account, partner, analytic reference, payment, and reconciliation<\/td>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;\">Are accounting moves balanced and linked to the underlying transaction?<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;border-right:1px solid #e4e0e9;\"><strong>Service history<\/strong><br \/>After Sales, Handover, and Customer Experience<\/td>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;border-right:1px solid #e4e0e9;\">Customer, contract, unit, request, milestone, and responsible team<\/td>\n<td style=\"padding:16px 18px;vertical-align:top;line-height:1.5;border-top:1px solid #e4e0e9;\">Can service teams continue the customer journey without rebuilding context?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3>Include what must remain operational, not everything that exists<\/h3>\n<p>Attachments, system chatter, obsolete configuration, unused CRM history, duplicated contacts, and expired technical records can increase complexity without improving continuity. They may be archived outside the operational database when legal, audit, and access requirements allow it.<\/p>\n<p>The correct boundary is organization-specific. It should be approved by commercial, collection, finance, customer-service, legal, and technology owners\u2014not decided only by the implementation team. The agreed boundary should name both inclusions and exclusions so that nobody assumes \u201cfull history\u201d means every file and every technical log.<\/p>\n<blockquote>\n<p><strong>Scope test:<\/strong> If removing a record prevents the organization from explaining a customer obligation, a collection position, an accounting balance, or a required service action, it probably belongs in the governed migration scope.<\/p>\n<\/blockquote>\n<h2 id=\"migration-method\">A six-stage governed migration method<\/h2>\n<p>A controlled migration is a sequence of business and technical decisions. It is not merely an import task. Archer\u2019s broader <a href=\"https:\/\/archer.solutions\/ar\/%d9%85%d9%86%d9%87%d8%ac%d9%8a%d8%a9-%d8%aa%d9%86%d9%81%d9%8a%d8%b0-erp\/\">ERP implementation approach<\/a> places migration inside a governed delivery program; the six stages below focus on the historical-data path.<\/p>\n<figure class=\"wp-caption aligncenter\" style=\"width:100%;max-width:100%;\"><img decoding=\"async\" src=\"https:\/\/archer.solutions\/wp-content\/uploads\/2026\/09\/governed-migration-process-v1.png\" alt=\"Six-stage real estate ERP data migration process covering assessment, scope, mapping, rehearsal, validation, and cutover\" style=\"display:block;width:100%;height:auto;\"><figcaption class=\"wp-caption-text\">A governed migration moves from source assessment and scope control to semantic mapping, rehearsal, validation, and accepted cutover.<\/figcaption><\/figure>\n<h3>1. Assess the source condition<\/h3>\n<p>Identify every source system, database, spreadsheet, document archive, integration, and manual process that may contain required history. Profile completeness, duplicates, invalid references, inconsistent dates, unbalanced values, missing identifiers, and differences between commercial and financial totals. The assessment should also reveal whether the source is operational, partially documented, or limited to technical evidence.<\/p>\n<h3>2. Scope the required operating history<\/h3>\n<p>Define legal companies, projects, date boundaries, business domains, owners, exclusions, acceptance criteria, and cutover constraints. Separate historical conversion from desired process redesign wherever possible. Combining every workflow improvement with migration makes it harder to isolate defects and approve the result.<\/p>\n<h3>3. Map business meaning to the target<\/h3>\n<p>A semantic map explains what each legacy object means and how it participates in the operating lifecycle. For example, a legacy \u201cpayment\u201d may represent a receipt, a cheque, an allocation, or an accounting posting. Those meanings may belong in separate target objects even if they occupied one legacy table.<\/p>\n<p>Transformations should be controlled, repeatable, and reviewable. Duplicate handling, identifier matching, date conversion, rounding treatment, status mapping, and company assignment require explicit rules. Material exceptions need named business owners and an auditable disposition. Cleaning is not permission to rewrite business history merely to make the target accept it.<\/p>\n<h3>4. Rehearse in a clean, representative environment<\/h3>\n<p>A rehearsal loads the complete approved dataset into a safe target, runs automated controls, and lets business teams inspect customer statements and operational scenarios. The team should be able to repeat the conversion from a clean target. A process that works only after undocumented manual repair is not a dependable cutover method.<\/p>\n<h3>5. Validate structure, finance, operations, and scope<\/h3>\n<p>Validation must establish more than record counts. It should prove that required relationships exist, financial totals reconcile, accounting entries are balanced, customer histories remain understandable, and excluded records did not leak into the target. Business users must test the outputs they will actually rely on.<\/p>\n<h3>6. Cut over only after business acceptance<\/h3>\n<p>The cutover plan controls the final source freeze, delta extraction, import order, validation, approval, user access, rollback decision, and opening support period. Go-live should follow evidence-based acceptance, not pressure from the calendar.<\/p>\n<h2 id=\"migration-validation\">How should migrated real estate data be validated?<\/h2>\n<p>Validation should answer four distinct questions:<\/p>\n<ol>\n<li><strong>Structural integrity:<\/strong> Are identifiers unique, parent-child records complete, and contracts linked to valid customers, units, schedules, payments, and cheques?<\/li>\n<li><strong>Financial integrity:<\/strong> Do balances reconcile, accounting entries remain balanced, and allocations, payments, cheques, and reconciliations retain their approved treatment?<\/li>\n<li><strong>Operational continuity:<\/strong> Can users produce a customer statement, review outstanding installments, trace a receipt, identify unit status, and continue approved service activity?<\/li>\n<li><strong>Scope integrity:<\/strong> Are approved inclusions complete, defined exclusions absent, and unsupported workflows clearly outside the delivered boundary?<\/li>\n<\/ol>\n<p>Automated tests provide breadth, but business acceptance provides meaning. Finance should inspect reconciliations and balances. Commercial and collection teams should test active customer journeys. Customer-service teams should confirm that the history required for After Sales or Handover remains understandable. Technology should confirm repeatability, performance, access control, and the final cutover sequence.<\/p>\n<h3>What belongs in a migration acceptance pack?<\/h3>\n<ul>\n<li>Approved scope, source list, date boundary, and exclusion register.<\/li>\n<li>Record counts by company, project, object, and status where meaningful.<\/li>\n<li>Relationship checks for the customer\u2013unit\u2013contract\u2013installment\u2013payment chain.<\/li>\n<li>Financial totals, balanced-entry controls, allocations, and reconciliation evidence.<\/li>\n<li>Sample customer statements and end-to-end operational scenarios.<\/li>\n<li>Exception log with owner, decision, treatment, and approval.<\/li>\n<li>Rehearsal results, final cutover results, and named business acceptance.<\/li>\n<\/ul>\n<h2 id=\"published-evidence\">What does published real estate delivery evidence show?<\/h2>\n<p>The following Archer Solutions case studies illustrate different migration conditions. They are not universal promises. Each describes a specific client, source condition, scope, and delivery result.<\/p>\n<h3>New Jersey Developments: an extreme recovery scenario<\/h3>\n<p>Most migrations begin with an operating source system and accessible implementation knowledge. New Jersey Developments presented a substantially more difficult condition: a non-operational Odoo 14 environment, incomplete source code, and a final database dump without a complete functional handover.<\/p>\n<p>Archer Solutions reconstructed the relationships connecting companies, projects, units, customers, contracts, installments, payments, cheques, and accounting before performing a business-semantic conversion into Odoo 18. The approved public case records 1,710 units, 39,015 installments, and 49,606 payments, with independent validation closing at 282 passes, no warnings, and no blockers. NJD is not a normal migration baseline; it demonstrates additional controls that may be required when the source environment is incomplete or no longer dependable.<\/p>\n<p><a href=\"https:\/\/archer.solutions\/ar\/case-studies\/real-estate-new-jersey-developments\/\">Review the Odoo 14-to-18 recovery for New Jersey Developments<\/a>.<\/p>\n<h3>El Nasr Housing &amp; Development: long-lived historical records<\/h3>\n<p>El Nasr\u2019s transformation replaced local software, spreadsheets, and paper-based processes with an on-premise Odoo 15 environment for 150 users. Because approximately 40 years of payment, customer, property, project, and financial history could not be exported reliably, the work used direct database access and controlled data-science techniques to recognize, reconstruct, clean, validate, and migrate the required records.<\/p>\n<p><a href=\"https:\/\/archer.solutions\/ar\/case-studies\/real-estate-el-nasr-housing-development\/\">See how El Nasr\u2019s historical data was modernized<\/a>.<\/p>\n<h3>Reach Real Estate: API-based scripted migration<\/h3>\n<p>Reach\u2019s multinational Odoo 18 program required a more technical migration route than the usual Excel extraction-and-upload cycle. Archer built a purpose-designed migration script using APIs to move historical records into the governed environment. The program transferred approximately 200,000 historical leads from the group\u2019s marketing platform and migrated units, contracts, payments, and wider operational records for 175 users across eight country operations.<\/p>\n<p><a href=\"https:\/\/archer.solutions\/ar\/case-studies\/real-estate-reach-real-estate\/\">Read the Reach Real Estate implementation case study<\/a>.<\/p>\n<h2 id=\"buyer-questions\">Questions to ask before approving a migration<\/h2>\n<p>Buyers should expect precise answers to these questions before treating a migration plan as implementation-ready:<\/p>\n<p>Migration planning is also a useful test of an implementation partner\u2019s architecture, governance, and delivery evidence. For a broader selection framework, use Archer Solutions\u2019 <a href=\"https:\/\/archer.solutions\/ar\/2026\/09\/23\/real-estate-erp-implementation-partner\/\">10-point real estate ERP implementation partner evaluation matrix<\/a>.<\/p>\n<ol>\n<li><strong>What must the new system explain on day one?<\/strong> Name the customer, collection, financial, service, and management decisions that depend on history.<\/li>\n<li><strong>Which source is authoritative when systems disagree?<\/strong> Define ownership and escalation instead of allowing the technical team to guess.<\/li>\n<li><strong>How will business meaning be reconstructed?<\/strong> Ask for mappings of statuses, relationships, allocations, amendments, and company boundaries\u2014not only a field list.<\/li>\n<li><strong>Which records are deliberately excluded?<\/strong> A clear exclusion register is evidence of scope control, not a sign of incomplete work.<\/li>\n<li><strong>Can the migration be repeated from a clean target?<\/strong> Repeatability reduces manual fixes and makes final cutover more dependable.<\/li>\n<li><strong>Which automated and business controls determine acceptance?<\/strong> Counts, relationships, balances, statements, scenarios, and named approvals should all be visible.<\/li>\n<li><strong>What happens if final validation fails?<\/strong> The cutover plan should define rollback, decision authority, communications, and the next safe window.<\/li>\n<\/ol>\n<blockquote>\n<p><strong>Warning signs:<\/strong> Be cautious when a proposal promises to \u201cmigrate everything,\u201d measures success only by row counts, has no exclusion register, leaves acceptance entirely to IT, or schedules go-live before a complete rehearsal.<\/p>\n<\/blockquote>\n<h2 id=\"conclusion\">Migration succeeds when the business can trust the history<\/h2>\n<p>Years of real estate data can be moved safely when scope, meaning, relationships, validation, and acceptance are treated as one controlled program. Preserve the records that explain customer obligations and financial truth, archive what does not belong in the operating system, and refuse cutover until the complete commercial-to-financial chain works in the target environment.<\/p>\n<p>To compare the evidence behind different implementation conditions, browse Archer Solutions\u2019 <a href=\"https:\/\/archer.solutions\/ar\/%d8%af%d8%b1%d8%a7%d8%b3%d8%a7%d8%aa-%d8%a7%d9%84%d8%ad%d8%a7%d9%84%d8%a9\/\">published ERP case studies<\/a>. If you are defining the source boundary, validation controls, or cutover plan for an upcoming project, <a href=\"https:\/\/archer.solutions\/ar\/%d9%86%d8%a7%d9%82%d8%b4-%d9%85%d8%b4%d8%b1%d9%88%d8%b9-%d9%86%d8%b8%d8%a7%d9%85-%d8%aa%d8%ae%d8%b7%d9%8a%d8%b7-%d9%85%d9%88%d8%a7%d8%b1%d8%af-%d8%a7%d9%84%d9%85%d8%a4%d8%b3%d8%b3%d8%a7%d8%aa-erp\/\">discuss your real estate ERP migration with Archer Solutions<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Real estate ERP data migration often begins only after a developer has operated for years on its core system. During that time, projects, buildings, units, reservations, contracts, amendments, payment schedules, receipts, cheques, broker records, customer statements, service requests, and accounting entries accumulate across software, spreadsheets, local databases, and paper files. The migration question is therefore [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":612,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[39],"tags":[41,40],"class_list":["post-894","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-real-estate-erp-ar","tag-implementation-planning-ar","tag-data-migration-upgrades-ar"],"_links":{"self":[{"href":"https:\/\/archer.solutions\/ar\/wp-json\/wp\/v2\/posts\/894","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archer.solutions\/ar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/archer.solutions\/ar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/archer.solutions\/ar\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/archer.solutions\/ar\/wp-json\/wp\/v2\/comments?post=894"}],"version-history":[{"count":1,"href":"https:\/\/archer.solutions\/ar\/wp-json\/wp\/v2\/posts\/894\/revisions"}],"predecessor-version":[{"id":896,"href":"https:\/\/archer.solutions\/ar\/wp-json\/wp\/v2\/posts\/894\/revisions\/896"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/archer.solutions\/ar\/wp-json\/wp\/v2\/media\/612"}],"wp:attachment":[{"href":"https:\/\/archer.solutions\/ar\/wp-json\/wp\/v2\/media?parent=894"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archer.solutions\/ar\/wp-json\/wp\/v2\/categories?post=894"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archer.solutions\/ar\/wp-json\/wp\/v2\/tags?post=894"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}