Summary

  • Jade Software should be evaluated through the accepted enterprise application record: whether data models, workflow state, integrations, release history, user access, audit trails, hosting evidence and support context remain coherent after years of customer-specific change.
  • Public evidence supports a Christchurch-rooted company registered in New Zealand, with offices in Christchurch, Auckland, Dunedin, Sydney, York and a Melbourne remote team; products and services span Jade Platform, application modernisation, managed services, regulatory-compliance software, Jade ThirdEye and Jade ICM.
  • The strongest operating evidence comes from long-lived, record-heavy customer settings: Skipton mortgage and savings processing, Fonterra milk payment workflows, DB Cargo order-to-cash and planning systems, and investigation or AML case-management products where a bad record is not merely a user-experience problem.
  • AS45172, described in public APNIC-derived records as Jade Software Corporation Christchurch ASN, is useful network-resource evidence. It does not prove where every Jade customer system is hosted, how resilient services are, or whether a particular SaaS instance is available.
  • The uncertainty boundary is material. Public pages and selected case studies do not expose private source code, uptime histories, support tickets, defect rates, security reports, customer economics or migration plans.

The real unit is the accepted application record

Jade Software is easy to describe by product names. Jade Platform is a development and runtime platform. Jade Services covers modernisation, API management, compliance work, business continuity and managed services. Jade ThirdEye is anti-money-laundering software. Jade ICM is investigations case management. The wider public footprint includes customer examples in banking, insurance, dairy payments, rail freight, investigation work and other record-heavy industries. That product list is useful, but it is not the buyer's real risk.

The buyer's risk is whether an important business action becomes an accepted application record and stays trustworthy over time. A mortgage application, a savings account update, a milk supplier payment, a rail freight order, a suspicious-activity alert, an investigation task or a customer-service workflow is only valuable if the software preserves the facts that make it valid: who acted, what data was used, which rule or model applied, what changed, which connected system received the change, which exception was raised, which user accepted it, how it can be audited, and who owns support when something looks wrong later.

That is why Jade Software should be judged by the accepted business application record, not by platform longevity alone. Longevity can be a strength. It can mean stable customer relationships, deep domain understanding and systems that have survived several technology cycles. It can also mean lock-in, scarce specialist skills, old deployment patterns, migration risk and a backlog of business rules that nobody wants to touch. The difference is evidence. If the application record remains explainable, tested, monitored, recoverable and supportable, longevity is an operating asset.

If the record only works because a small group of specialists remembers how it behaves, longevity becomes a hidden liability.

Jade's own public positioning makes this the right test. The Jade Software home page presents the company around enterprise software for corporate clients and says Jade Platform supports enterprise-grade technology change. The Jade Platform page describes an end-to-end development and runtime platform spanning runtime, integrated development environment, database and dedicated language. The Developer Centre describes Jade Platform as integrating an entity-oriented database, programming language and development environment so developers can define complex data models and build dependable applications. The application modernisation page frames modernisation as a balance between replacement, rebuild and incremental extension of existing investments.

Those pages point to the same commercial question. Jade is not selling a disposable app layer. It is selling, supporting and modernising software that often sits close to the customer's operating truth. That makes the accepted record the practical unit of value.

Identity, footprint and the network clue

The public identity boundary matters because the name "Jade" collides with gemstones, other software projects and unrelated brands. The relevant company is Jade Software Corporation Limited, the New Zealand software company behind Jadeworld and Jade Platform. Company Hub, drawing from New Zealand Companies Office data, lists JADE SOFTWARE CORPORATION LIMITED with company number 345150, NZBN 9429039604873, registered status, a May 3, 1987 registration date, and an office, registered and service address at 5 Sir Gil Simpson Drive, Burnside, Christchurch 8053. The official contact page lists Christchurch as headquarters at the same Burnside address, plus Auckland, Dunedin, Sydney, York and a Melbourne remote team.

The company is also part of a larger ownership context. A 2023 Jade announcement said Justin Mercer had been appointed chief executive and that Jade was fully owned by United Kingdom-based Skipton Group. Skipton Group's own brands page describes Jade as a New Zealand-based software organisation whose platforms support software critical to ports, hospitals, farms, warehouses, banks and insurers. Skipton Building Society's 2024 annual report described Jade as its New Zealand-based AI-software business and reported that Jade increased profitability to GBP1.4 million in 2024. Those statements support the group boundary, but they do not by themselves prove product performance.

The directory label also carries a network clue: AS45172. Public BGP and APNIC-derived records from bgp.tools describe AS45172 as Jade Software Corporation Christchurch ASN, registered on April 4, 2008, active and allocated under APNIC, with aut-num AS45172, as-name JADE-NZ-AS-AP, country NZ and organisation ORG-JSCL1-AP. The APNIC Whois organisation record for ORG-JSCL1-AP lists Jade Software Corporation Limited as an LIR in New Zealand and gives the Burnside Christchurch address. IPinfo's AS45172 page likewise identifies the registered name as Jade Software Corporation Christchurch ASN, country New Zealand, domain jadeworld.com, one hosted domain signal and no displayed IPv6 addresses in its summary.

That evidence is useful but bounded. An autonomous system number is a routing and resource-administration signal. It can show that Jade has, or has had, a public Internet numbering and routing footprint under its name. It can support questions about hosting, address space, route origin, resilience and operational dependency. It does not prove that all Jade applications run on that network. It does not prove customer uptime. It does not prove cloud architecture, data residency, backup quality, incident response or whether any particular customer workload is hosted by Jade, Azure, a customer environment or a managed hybrid arrangement.

This distinction is important because Jade's own public material spans on-premise, cloud, managed service and modernisation contexts. The network record is evidence, not the entity. It belongs in the diligence file because enterprise application records depend on networks, identity, DNS, hosting and support paths. It should not be turned into a claim that AS45172 is the product.

Jade Platform turns data model truth into lock-in risk

Jade Platform is the center of the technical story because it explains both the value and the lock-in. The About Jade Platform page says Jade Platform, formerly JADE, is made by Jade Software Corporation and lets developers define code and database in a single development environment. It describes an entity-oriented database and entity-oriented language at the core of the platform and says the platform is used by banks, building societies, insurers, ports, law enforcement, health, agriculture and retail organisations. The history page says JADE 3.3, released in 1996, had its own language, multi-user development environment, entity-oriented database engine and distributed runtime environment.

That architecture is not a normal SaaS wrapper around a commodity database. It is a platform model where application logic and data structure can be closely coupled. The advantage is that a business domain can be represented directly: mortgage accounts, milk payment rules, investigation entities, evidence records, supplier deductions, freight orders, user actions and workflows can live in a model designed around the operating problem rather than squeezed into a generic package.

The risk is that the same tight fit can make change harder when a customer wants new cloud patterns, new APIs, different reporting tools, new security controls, new integration architecture or a larger pool of developers.

For a Jade customer, the accepted record has to include the data model. It is not enough that a screen saves. The buyer should know how classes, relationships, persistent entities, transactions, audit fields, secondary databases, APIs and external reporting views map to the business facts the organisation relies on. If the data model carries decades of business exceptions, that is valuable knowledge. It is also migration gravity.

The public Jade Platform material acknowledges the continuity side of this. The platform page highlights support, managed services, training, consultancy, development and user-experience services. The features page points to Synchronized Database Service, single sign-on and collection concurrency. The SDS page describes secondary databases for disaster recovery and query workload offloading, with access to entities in secondary databases while updates are applied. The release policy explains the 2025 naming convention, including Jade 2025 R1, R2 and R3. The documentation page lists release documentation for Jade Platform 2025, 2022 and 2020.

That release and documentation infrastructure matters. A platform that supports long-lived enterprise systems has to make version movement, high availability, developer training and support legible. It cannot rely only on relationship memory. Buyers should treat every Jade Platform engagement as a life-cycle question: which version is in use, which release is supported, which extension points are active, what test coverage protects change, how secondary databases are configured, how APIs are governed, how deployment works, and how a customer can add or replace developers without breaking the record.

The useful commercial reading is not that Jade Platform is too old or uniquely risky. The better reading is that Jade is selling a high-context platform for high-context systems. That can be excellent where the system is deeply differentiated. It can be expensive where the system should have been standardised.

Modernisation is Jade's practical control surface

The modernisation pages show how Jade wants customers to handle older systems without treating replacement as the only respectable option. Jade's application modernisation page presents replace, rebuild and modernise as separate choices. It says replacement may create functional compromise, hidden integration cost and business process change, while rebuilding can require large investment of capital, time and resources. Modernisation is presented as an incremental path that can extend the life of existing investments while reducing risk and business impact.

That framing is credible because many enterprise systems fail modernisation programs through ambition, not age. A bank, insurer, logistics operator or cooperative payment system may not be able to stop the business long enough to replace the record system cleanly. The existing system may contain rules that no product team has fully documented. Some old screens may look dated while the underlying transaction rules remain valuable. Some workflows may be politically difficult to standardise because they encode real business exceptions.

Jade lists four modernisation moves: encapsulate, refactor, rehost and rebuild. Encapsulation exposes existing data and functions as services through APIs. Refactoring restructures and optimises existing code to simplify and reduce risk. Rehosting moves an application to cloud without changing code or functionality. Rebuilding starts from the ground up with cloud-native architecture, modern front ends and DevOps tooling. Those four words are not merely consulting taxonomy. They are different levels of record risk.

Encapsulation can make a stable core useful to new channels, but it can also hide old assumptions behind APIs. The accepted record should include API contracts, versioning, security policy, monitoring, error handling and documentation. Refactoring can reduce complexity, but it can also alter behaviour if regression tests are weak. The accepted record should include before-and-after behaviour checks and a map of intentionally removed functions. Rehosting can improve infrastructure economics and resilience, but it can expose assumptions about latency, file paths, identity, batch windows, monitoring and backup.

The accepted record should include environment definitions, recovery tests and incident playbooks. Rebuilding can free the customer from platform constraints, but it carries the highest risk of losing quiet business rules. The accepted record should include data migration evidence, reconciliation reports, user acceptance criteria and post-launch defect handling.

The API management page makes the same point from the integration side. It warns that decentralised point-to-point integrations can create a tangle of dependencies and says centralised API management should cover security, encryption, version control, deployment, monitoring, analytics, scalability and reliability. That is exactly the evidence a buyer should demand if Jade is connecting a long-lived core to newer portals, partner systems, mobile apps or analytics tools.

The modernisation value case is therefore not "newer technology is better." It is "change should not destroy record truth." Jade's public service language is strongest when read that way.

Customer examples show record-heavy domains

Jade's selected public case studies are useful because they involve domains where the record matters more than the interface. They should still be treated as vendor-selected evidence, not independent audits.

The Fonterra case study says Fonterra engaged Jade to develop Aspire, a milk payment system. It says Aspire is built on Jade Platform, facilitates millions of dollars of payments across a complex network of shareholders, contractors and suppliers, offers near real-time processing of data, shares information between multiple systems and considers cooperative shareholding rules, payments to multiple parties and deductions to third parties. That is a clean example of the accepted-record problem. A milk payment system is not valuable because it has a pleasing screen. It is valuable if supplier identity, volume, calculation rules, cooperative shares, deductions, third-party payments and connected systems agree.

The DB Cargo case study describes two systems: a customer-ordering system and a consolidated planning tool. DB Cargo wanted to improve order-to-cash processes that had been run through spreadsheets and manual processes, and Jade's public account says the portal minimum viable product was hosted by Jade in Azure and connected back to the core Jade Platform DB Cargo system. Here the acceptance test is order continuity. A freight order has to move from customer request to planning, fulfilment, billing and reporting without disappearing into a spreadsheet exception. A portal that looks modern but loses order state is a failure. A core system that stays reliable but cannot connect to customers is also a failure. The value is in the connection between the new channel and the existing record.

The Skipton Building Society Jade Platform case study says Skipton uses Jade Platform to support mortgage and savings account processing from application through account closure. It says Skipton moved from Unisys LINC to a server-based solution around 2002/2003 using Jade's JET process, made use of entity-oriented capabilities, exported data to SQL for data warehousing, used secondary and delta capabilities for high availability while overnight batch was running, and expected future movement toward Azure. That is perhaps the clearest example of platform longevity as both asset and dependency. A mortgage and savings core cannot be casually replaced. The accepted record must survive batch windows, data warehouse extraction, account life-cycle events, high availability needs and eventual cloud plans.

The Jade Services Skipton document repository case study adds another record type: document access. It says tens of thousands of documents are created, scanned, updated and accessed across multiple locations. The public page is not a full system description, but it shows why document systems in financial services are not just storage. They are evidence systems. The accepted record must include document identity, retention, permissions, access, auditability, migration and recovery.

Jade ICM and ThirdEye extend the same theme into investigative and compliance records. The Jade ICM page says the product centralises and shares information, helps teams discover lines of enquiry, manage evidence, prepare for prosecutions, assign, record and track case aspects, connect and search multiple datasets, visualise case information and create a central system of record. The 2025 ICM release notes show the product is still being maintained with home-screen, case, search, usability, property and administration changes. The ThirdEye AML case study describes customer screening, transaction monitoring, suspicious-activity alerts and suspicious transaction reports. Jade's own ethics blog says ThirdEye used rule-based algorithms to raise suspicious-transaction alerts with human oversight by compliance officers.

Across these examples, the pattern is consistent. Jade is strongest where the application has to be a durable system of record for a complicated business domain. That is also where procurement should be most demanding.

Automation value depends on exception handling

Enterprise automation is often sold as faster processing. In Jade's domains, speed is secondary to exception handling. A payment, investigation, freight order or mortgage workflow is not accepted because it moves quickly through the happy path. It is accepted because the software can handle the partial, late, disputed, corrected, unusual or regulated case without corrupting the record.

Fonterra's supplier payment example makes this visible. Cooperative shareholding rules, payments to multiple parties and deductions to third parties create exceptions by design. DB Cargo's order-to-cash example involves operations where delays or changes can ripple through planning, customer expectations and billing. Skipton's mortgage and savings processing involves application states, account closure, data export and availability during batch. ICM involves cases, evidence, property, tasks, relationships and searches. ThirdEye involves alerts that require human review rather than automatic punishment.

For buyers, this changes the acceptance criteria. Do not ask only whether Jade can automate the main workflow. Ask how exceptions are represented. Ask what happens if a connected system rejects a message. Ask how duplicate records are detected. Ask how a user corrects a wrong value after a downstream integration has already acted on it. Ask how evidence is preserved when a decision is reversed. Ask how reports distinguish pending, accepted, rejected, closed and manually overridden states. Ask how batch and real-time processing interact. Ask how the customer can reconstruct the record six months later.

This is especially important in regulated settings. Jade's regulatory compliance page says it uses auditable workflow management and automated tests in delivery, and provides ongoing monitoring and support to maintain compliance as regulation changes. That is the right vocabulary. But the public page does not prove any specific customer's compliance. The buyer still needs implementation evidence: test suites, audit trails, control mapping, role permissions, change logs, support model, incident handling and documentation.

The neutral standard to apply here is not a feature checklist. ISO/IEC/IEEE 12207 frames software through life-cycle processes, including acquisition, supply, development, operation and maintenance. NIST's Secure Software Development Framework recommends secure development practices that can be integrated into the software life cycle. OWASP ASVS gives a basis for verifying application security controls and secure development requirements. These standards do not certify Jade. They provide a language for buyers to ask whether the accepted record is secure, testable and maintainable.

Hosting and cloud evidence must be read carefully

Jade's public material includes both cloud and non-cloud language. The category for this article is cloud service, but the company should not be treated as a pure cloud-native SaaS vendor. Jade is better understood as a provider of enterprise software, platform support, modernisation and managed services across on-premise, hosted, cloud and hybrid situations.

That distinction matters. A SaaS buyer may expect the vendor to control most of the stack. A modernisation buyer may keep parts of the application in its own environment. A Jade Platform partner may build and operate its own product on Jade Platform. A customer may use Azure for a portal while retaining a core Jade Platform system elsewhere. Public evidence supports all of these possibilities. DB Cargo's portal was described as hosted by Jade in Azure and connected to a core Jade Platform system. Skipton's Jade Platform case study discusses future cloud movement.

Jade's modernisation service page discusses rehosting to cloud without changing code. The platform page says Jade Platform can scale on-premise or in the cloud.

AS45172 then becomes a diligence signal rather than a conclusion. A buyer should ask which workloads, environments, DNS names, IP ranges, routes, VPNs, cloud tenants, identity providers and managed service desks are in scope. It should ask whether a Jade-hosted component depends on AS45172, a public cloud, a customer network, a third-party carrier, or some combination. It should ask how monitoring crosses those boundaries and who owns incidents when a problem appears between application, network and external integration.

Public BGP tools show AS45172 as active, with APNIC allocation and IPv4 prefixes. bgp.tools lists multiple import references in the APNIC entity and shows 18 originated IPv4 prefixes. IPinfo presents 65,280 IPv4 addresses and no IPv6 addresses for the ASN summary. These public views are enough to show a meaningful network-resource footprint. They are not enough to show redundancy quality, traffic engineering, DDoS protection, RPKI operations across every route, service-level performance, data-center location or incident history.

The network evidence is most useful when paired with architecture facts. If a customer has a business-critical Jade application, it should know which parts of the service depend on Jade-managed networks, which depend on cloud providers, which depend on customer connectivity, and how failures are isolated. Without that map, the application record may be correct but unreachable, or reachable but unable to complete downstream transactions.

Support continuity is the economic hinge

The commercial question is whether durable application control and local support exceed platform lock-in, modernisation, integration, hosting and specialist-labour costs. Jade's strongest public case for value is continuity. It has a long history, a Christchurch headquarters, regional offices, a parent group with financial-services roots, long-running platform releases, developer documentation, selected customer relationships and products built for high-consequence records.

Continuity can reduce risk. A customer with a legacy core can work with a vendor that understands the original platform, the migration history and the domain. A modernisation effort can preserve working business rules rather than attempting a risky replacement. A managed services arrangement can keep specialist skills available. A platform vendor can align product changes with the needs of customers that have deep operational dependencies.

Continuity can also increase dependence. If only Jade or a small Jade-specialist partner pool can maintain the system, the customer may have limited negotiating leverage. If the data model is hard to extract, migration becomes expensive. If release upgrades require scarce expertise, version lag can accumulate. If customisations are poorly documented, new APIs and cloud moves can become fragile. If support knowledge sits with named people rather than recorded artifacts, staff turnover becomes a system risk.

The buyer's diligence should therefore focus on support evidence, not just product history. Ask which versions are supported and for how long. Ask whether the customer has access to documentation, training and developer resources. Ask how issues are triaged. Ask how emergency support works across New Zealand, Australia and the United Kingdom time zones. Ask whether there is a named service desk, a runbook, an escalation path and a post-incident review process. Ask how Jade handles knowledge transfer when engineers change. Ask how customer-specific extensions are documented.

Ask what happens if the customer wants a third party to support part of the stack.

The B Corp listing and Skipton ownership context are not product proof, but they contribute to continuity diligence. B Lab lists Jade Software Corporation Ltd as a Certified B Corporation since December 2023, headquartered in Canterbury Region, New Zealand, operating in Australia, Canada, Ireland, New Zealand and the United Kingdom, with an 80.5 B Impact score. Skipton Group lists Jade as one of its brands. These facts suggest institutional form and public accountability signals. They do not replace operational service evidence.

In other words, Jade's economic value sits in the space between specialist platform knowledge and transferable customer control. A buyer should pay for the first without surrendering the second.

Where Jade looks strongest

Jade looks strongest in environments where the system of record is too differentiated, too old, too integrated or too regulated for a simple package swap. The public examples point to mortgage and savings processing, dairy supplier payments, freight order-to-cash, investigation case management, AML screening, insurance portals, document repositories and application modernisation in regulated industries. These are not casual productivity apps. They are systems where record correctness, auditability, integration and long-term support decide whether the software is trusted.

The company also looks strongest where a customer wants incremental modernisation rather than a heroic rewrite. Encapsulating an existing core behind APIs, refactoring risky code, moving stable workloads to cloud infrastructure, adding a portal to a back-end record, or maintaining compliance workflows can all be rational if the existing system contains business logic that still matters. Jade's public service language is well matched to that kind of work.

The local New Zealand identity is also part of the value. Christchurch is not just a mailing address in the public evidence. It is headquarters, company registration address, APNIC organisation address and the geography behind AS45172. For New Zealand and Australian customers, that local base may support relationship continuity, regional context and skilled-labour access. For global customers, it gives Jade a distinct Asia-Pacific software identity rather than making it another anonymous outsourcing or SaaS brand.

Jade's product diversity is a secondary strength. Jade Platform, ICM, ThirdEye and services are not the same product, but they reinforce a shared operating thesis: capture domain-specific facts, preserve workflow state, support evidence, modernise without losing the core record, and provide specialist help. That is coherent.

The strongest conclusion supported by public evidence is that Jade is a credible, long-lived enterprise-software company for high-context record systems. The unsupported conclusion would be that every Jade customer receives excellent uptime, low-cost modernisation, perfect migration paths or easy exit options. Public evidence does not prove that.

The main risks

The first risk is platform lock-in. Jade Platform's integrated entity-oriented model can be powerful, but it can also bind business logic, data structure and developer skills tightly together. A customer should know whether it is buying a long-term partnership, a transferable system or a bridge to another platform. Each answer is valid only if the contract, documentation and staffing plan match it.

The second risk is modernisation ambiguity. "Modernise" can mean API wrapping, code cleanup, cloud rehosting, user-interface refresh, data export, security hardening or full rebuild. These are different projects with different risks. Buyers should not accept a vague roadmap. They should require sequenced decisions, measurable acceptance criteria and rollback plans.

The third risk is integration fragility. Jade's public API management page correctly warns about point-to-point dependency tangles. That risk is real in any record-heavy enterprise. Every connected system should have an owner, contract, monitoring view, retry rule, error state and version policy. Otherwise a clean Jade record can still fail in the business process because a connected service silently rejected or transformed it.

The fourth risk is support concentration. A long-lived platform can develop a narrow labour market. Buyers should ask how Jade trains developers, how partners are used, how documentation is maintained, and how customer teams can become competent enough to challenge and verify vendor work. A customer that cannot inspect or understand its own record system is not in control.

The fifth risk is network and hosting opacity. AS45172 gives a public resource clue, but it does not provide a full operating map. Buyers should demand a clear architecture view showing which networks, clouds, sites, DNS records, backups, monitoring tools and third parties are involved. If the service is hybrid, the incident model must be hybrid too.

The sixth risk is case-study overreach. Fonterra, DB Cargo, Skipton, ICM and ThirdEye examples show patterns, not portfolio-wide proof. A selected case study can be accurate and still not representative. Buyers should ask for references, sample deliverables, security evidence, test artifacts, support reports and migration plans relevant to their own system.

What a buyer should demand before acceptance

For Jade or any similar enterprise-software provider, acceptance should be written around the record, not around the demo.

The first group is data-model evidence. The buyer should receive a domain map explaining core entities, relationships, identifiers, validation rules, state transitions, audit fields, history retention and reporting views. Where Jade Platform is involved, the map should explain what is native to Jade, what is exposed to SQL or external tools, and what is duplicated for integration.

The second group is workflow evidence. Every critical workflow should have accepted states, exception states, user roles, permissions, notifications, approvals, reversals, reports and audit events. A user should be able to explain what "accepted" means for a payment, mortgage account, freight order, evidence item, alert or document.

The third group is integration evidence. API contracts, message schemas, batch schedules, retry behaviour, error queues, monitoring dashboards, versioning policies, authentication, encryption and data ownership should be documented. For API management work, the buyer should see a catalogue of reusable APIs and know which ones are business-critical.

The fourth group is release and test evidence. The buyer should know the Jade Platform or product version, support status, upgrade path, regression test coverage, automated test results, performance assumptions, security testing approach and known defects. If the work involves ICM, ThirdEye or a customer-specific system, release notes and customer-specific configuration should be linked to acceptance.

The fifth group is hosting and resilience evidence. The buyer should know where the application runs, which networks are involved, whether AS45172 is relevant, which cloud provider or data center is used, how backups and secondary systems work, how failover is tested, how recovery objectives are defined and how monitoring is shared.

The sixth group is support and exit evidence. The customer should receive runbooks, escalation paths, service hours, maintenance windows, knowledge-transfer materials, named roles, training options and an exit or transition plan. Exit does not have to mean leaving Jade. It means the customer understands how to change support model, add developers, migrate data or replace components without discovering too late that the record was not portable.

These demands are not hostile. They are the price of trusting a system that carries real business records.

Public uncertainty boundaries

This article relies on public evidence: official Jade Software and Jade Platform pages, official customer case studies, public company information, Skipton Group and Skipton Building Society materials, B Lab, APNIC Whois, BGP tools, IPinfo, and neutral software-delivery and security references from NIST, IEEE, OWASP and CISA. No Jade customer source code, production environment, cloud tenant, private support ticket, security report, contract, service-level report, invoice, defect database or architecture diagram was inspected.

Official Jade pages are strong evidence for what the company says it offers and how it describes selected work. They are weaker evidence for actual customer economics, defect rates, uptime, security quality and support performance. Customer case studies are useful because they identify record-heavy domains and describe project patterns. They are still vendor-selected. Public routing data is useful because it verifies a network-resource footprint. It is not a service availability test.

The neutral standards are used as evaluation criteria, not as proof of compliance. NIST SSDF, OWASP ASVS, CISA secure-by-design guidance and ISO/IEC/IEEE software life-cycle language help define what good evidence should look like for secure, maintainable software. They do not certify Jade.

The cautious conclusion is that Jade Software Corporation Christchurch ASN represents a long-lived New Zealand enterprise-software company whose public evidence aligns with systems where record continuity matters. The unresolved question is whether a particular Jade engagement gives the customer enough evidence, control and support continuity to justify the lock-in it may create.

Verdict

Jade Software should not be judged as a generic cloud vendor or as a BGP entry. It should be judged by whether the enterprise record survives change. The company's public footprint is unusually well suited to that question: a Christchurch headquarters, a New Zealand company record, Skipton ownership, public ASN evidence, a long-running proprietary platform, current release documentation, application modernisation services, managed services, and customer examples in banking, insurance, dairy payments, freight, investigations and AML.

That evidence supports a serious buying case. Jade appears strongest where the customer has a valuable, high-context core system that cannot be replaced casually and where the commercial goal is to modernise, expose, support or extend that system without losing the business truth embedded in it. It appears weaker where a customer wants low-dependency commodity software, broad labour-market substitutability or a clean exit from specialist platform knowledge.

The final procurement question is therefore simple to state and hard to answer: after Jade builds, modernises, hosts or supports the system, can the customer still explain the record? If the answer is yes, Jade's platform memory and local expertise can be a durable asset. If the answer is no, the same strengths can become a dependency trap. The difference lies in the evidence delivered with the software: data model, workflow state, integration contracts, release notes, tests, security controls, hosting map, support runbook and a credible path for future change.