The sheet suits integrators, MSPs and enterprise systems consultants whose client's history spans several generations of software. For a single transition, the S/4HANA transition guide covers the exception layer an SAP move leaves behind; for the delivery records an integrator firm holds itself, see systems integrator roll-ups. This page is the intake that comes before either.
SAPWhy platform history is worth writing down
SourceX's own application asks for it. Its how-it-works page says the company starts by listing its systems, years of history and what can be exported, after which SourceX checks fit, completes the inventory with the company, runs the rights check and sets the processing route. The same page says "qualifying companies list at least 5 systems, and no records are shared at this stage." Among the fit signals it names are volume, historical depth, data structure and clear ownership.
Historical depth is where an integrator's memory matters most. Whether a company has six years of work orders or fifteen often depends on what happened to a predecessor platform: migrated in full, left running read-only, exported to files, or switched off and deleted. The CEO rarely knows. The team that ran the cutover usually does, and it usually still has the project notes.
What the integrator does not decide is whether any of it fits. Relevance to SourceX's current data needs is assessed in review, criteria differ between programs, and a company that misses one program may suit another later. The sheet prepares a conversation; it does not predict an outcome.
The system-history and authority intake
The intake has three parts, filled in this order. If Part 1 stops, you never reach Part 2.
Part 1: company gates. Six lines, answered by the CEO or the sponsor in conversation, never from systems.
| Line | Ask | Passes when | Stops or waits when |
|---|---|---|---|
| 1. Operating entity | Which legal entity employs the people who created the records? | One named entity | Records sit in an entity nobody can name yet |
| 2. Peak headcount | What was full-time headcount at its highest, and when? | 50 or more at peak, contractors excluded | Below that, or only a seat count is known |
| 3. Location and language | Where is the company, and what language are its records in? | Inside the published geography | Outside it |
| 4. Earlier licensing | Has any of this data been licensed for AI training before? | No | Yes: already-licensed data is not eligible |
| 5. Ownership events | Was the company acquired, or is it in a formal process? | Stable, or the current controller is known | A process where the CEO alone may not be enough |
| 6. The CEO | Does the CEO know about the idea and want the conversation? | A dated yes | Not yet asked |
On line 3, the published rule is: Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 70% of the data is in English. On line 2, a staffing or managed-workforce client counts only its own full-time staff, never the workers it has placed on assignment with clients; give both figures separately and introduce the firm anyway if its records are strong. On line 5, once a sale has closed the acquirer's CEO decides for the business; before closing, the target's CEO does.
Part 2: one row per system. Eight columns, each filled from what you already hold or what the client tells you.
| Column | What you write | Where it comes from | What you never do to fill it |
|---|---|---|---|
| System role | ERP, field service, helpdesk, document store, in plain words | Your project files | Log in to check |
| In use from and to | Years, such as 2016 to now | Your project history or the client | Read database timestamps |
| Predecessor and its fate | Migrated, archived read-only, exported to files, or deleted | Cutover notes you already hold | Open the archive to confirm |
| Record types | "Work orders with technician notes", "invoices and credit memos" | The system owner's description | Pull examples |
| Created by | Company staff, customers, partners or a mix | The client | Infer it from the data |
| Scale | As the company states it, or "unknown" | The client | Run a count |
| Administered by | Your firm, the client's IT team or the software vendor | Contracts and access lists you manage | Change any access |
| Known limits | Customer contracts that may restrict reuse: yes, no or unknown | The client; rights review decides | Interpret the contract yourself |
Part 3: authority. Three lines: the internal sponsor who will carry the question, the CEO's answer with its date, and the person at your firm who signed the SourceX Channel Partner Agreement, which has to happen before anything is submitted.
Method note. The intake was assembled on 2026-10-27 from SourceX's screening page, its how-it-works page, the program terms (version 2026-10-22.2, since replaced by version 2026-11-04) and the unsigned Channel Partner Agreement sample (version 2026-10-19). Part 1 restates the published gates; Part 2 follows the application's own prompts (systems, years of history, what can be exported) plus the ownership questions the screening page raises; Part 3 applies the rule that the CEO authorizes. The sheet does not score demand, record quality or value, which only SourceX's review assesses, and it has not been tested on live client intakes.
Cutovers, sunsets and archive decisions
The sheet is worth filling when a dated event forces someone to decide what happens to old records. Four events come up most in integration work:
- A platform's end of support is announced, and the company must choose what to migrate and what to leave behind.
- Two companies' systems are being consolidated after an acquisition.
- A read-only archive is up for renewal, and finance asks whether it is still needed.
- A retention policy is being rewritten, and someone proposes deleting anything older than a set number of years.
Each event has a person who asked for the work: usually an IT director, a CFO or a COO. That person can sponsor the idea internally and help prepare the sheet. The decision to open a licensing discussion, and the signature, sit with the CEO. Real urgency comes from the event's documented date. A quarter-end, a sales target or "programs fill up" is not urgency.
The administrator column is not the authority column
Part 2 has an "administered by" column and Part 3 has a CEO line, and the two are never the same entry, even when the integrator administers everything.
NIST's glossary describes an information system owner as the official responsible for the overall procurement, development, integration, modification, or operation and maintenance of a system (paraphrase; the glossary itself warns that each definition belongs to the context of its source document). Every duty on that list is about running the system. None of them is about licensing what it holds. The partner agreement is explicit on the same point: section 4.2 of the sample says "This Agreement gives Partner no authority to share a supplier's inventory, records, raw data or personal information, or to access extraction systems."
Which party answers each column follows from that:
| Sheet part | Who answers | Who decides it |
|---|---|---|
| Part 1, company gates | The CEO or sponsor | SourceX, in review |
| Part 2, role, years and predecessors | The integrator, from its own project history | Nobody; it is a record of fact |
| Part 2, created by, scale and known limits | The client | SourceX's rights review |
| Part 3, the answer | The CEO | The CEO |
A related trap is the user count. The seats you administer are not the company's full-time headcount: contractors, shared mailboxes and service accounts inflate them, and staff who never needed that system are missing. Line 2 always comes from the company.
One sheet, filled in for a field-services company (Illustrative)
Illustrative. A 230-person commercial HVAC and field-services company, founder-led, with its peak full-time headcount reached in 2023. Its integrator has supported it since 2012. Part 1 passes on every line, and the CEO said yes on a dated call.
| System | In use | Predecessor and its fate | Created by | Administered by | Known limits | Result |
|---|---|---|---|---|---|---|
| Field-service work orders | 2016 to now | Paper dispatch sheets, scanned to a file share | Company technicians and dispatchers | The integrator | None known | Describe |
| Scanned dispatch archive | 2009 to 2016 | Not applicable; it is the predecessor | Company staff | The client's IT team | None known | Describe |
| ERP: orders and invoices | 2019 to now | Older ERP, archived read-only in 2019 | Company staff | The integrator | Unknown | Describe; limits to rights review |
| Archived older ERP | 2008 to 2019 | Not applicable; kept read-only | Company staff | The integrator | Unknown | Describe |
| Helpdesk tickets | 2012 to now | None | Support staff, with customer messages | The client's IT team | Unknown | Describe |
| 2010 to now | Moved from an on-premises server in 2018 | Staff and outside correspondents | The client's IT team | Personal data inside | Mention; scope set in review | |
| Customer portal uploads | 2020 to now | None | Customers | The software vendor | Customer terms | Leave out: customer-created |
| Legacy CRM | 2009 to 2017 | Deleted at the 2017 cutover | Company staff | Nobody now | Not applicable | Gone: nothing to describe |
Six systems reach the CEO as plain descriptions and two drop out: one because customers created its contents, one because nothing survives. Not one number on the sheet came from a query. The scale column stayed "as the company states it" for every row, and the company gave its own figures when it applied.
From sheet to introduction
The sheet describes the client's own systems, so it goes to the client first. Hand it to the CEO and let the CEO decide what to do with it. If the CEO wants to proceed, the person who signed the partner agreement submits the introduction through the partner link, and the company applies and lists its systems in its own words.
If the CEO asks you to include part of the sheet in the introduction, include only the lines the CEO approved: system roles and years, never figures you computed or anything a customer created. Leave out estimates of value and any statement that the company qualifies. Section 4.6 of the sample bars a partner from telling a referred company that an indicative estimate, positive interest, a signature or a data upload makes a purchase or reward certain.
Credit follows the terms, not the sheet. The first valid introduction of a new company within the 90-day window is credited once that company submits a verified application, and a company that already had an application, relationship, lead, account or email correspondence with SourceX is a duplicate that nobody is credited for. How the referral stays clear of your paid work, from invoices to ticket queues, is mapped in separating paid IT work from a referral; who runs a licensing project inside an EOS-style company is set out in EOS Integrator responsibilities.
Where the sheet misleads
- Your history has a start date. Systems retired before your firm arrived may be missing entirely. Mark the first year you can vouch for.
- An archive is not proof of records. A read-only system may hold less than its name suggests, or be readable only in a vendor format. Testing it is not your job; note it as "archived, condition unknown".
- "Created by" is a judgment. Helpdesk tickets mix staff notes with customer messages, and the line between the company's records and its clients' is drawn in rights review, not on your sheet. The customer implementation records page shows how mixed that line can be.
- Programs move. Criteria follow each program and change. A sheet is valid on the day you dated it.
- The fit checker is a screen, not a ruling. If the CEO wants a quick read before talking to anyone, the company fit checker gives a preliminary, non-binding answer.
Next step
Refer a company. No cap on rewards. Default reward on a company's first qualifying transaction: the greater of $50,000 plus 5% and 15% of Actual Supplier Payout, with no cap; further qualifying transactions first agreed within 12 months of the first Closing pay 15%. Eligibility and payment conditions apply, including the USD 100,000 Minimum Transaction, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
When Part 1 passes on every line and Part 3 holds the CEO's dated yes, create your partner account, compare the sheet once more with who qualifies and read the program terms before the introduction goes out; the implementation partners overview covers the program from the integrator's side.