Every vendor now says AI makes SAP projects faster. Few can show you how. If you plan a migration, you need a way to test those claims before you sign with any SAP Implementation Partner, and that starts with the right questions.
This guide gives Canadian buyers a practical question set. It covers architect review, parity evidence, scope limits and the code that no tool can convert automatically. Consultants will also see what serious buyers now expect. 2iSolutions, a Toronto-based SAP partner serving Canadian clients, built its AI services around the same checks.
Why Do AI Claims Need Testing Before You Sign?
Buyers should test AI claims because speed figures without evidence say nothing about quality. A fast result that breaks a pricing routine or a tax calculation costs more than a slow one. So ask for proof of method, review and results before you accept any promise.
Marketing language in this space is loose. One vendor says it scores your system environment in days. Another says it converts custom programs in minutes. Both may be true, but each claim hides a question. What happens after the tool finishes?
Consider a real project. A Canadian manufacturer has thousands of custom programs written over two decades. Some are dead. Some run payroll-adjacent logic nobody has touched since the original developer left. An AI tool can read all of them quickly, but it cannot know which ones the business still depends on.
So the test is not “does the partner use AI?” Everyone does. The test is whether the partner can explain where AI stops and human judgment begins.
Separate the tool from the service
A tool produces output. A service produces an outcome you can run in production. When you evaluate a bid, ask which part the partner automates and which part a named person owns.
This matters when you compare firms offering SAP Consulting Services Canada. Two proposals can quote the same timeline while one includes expert review and the other ships raw tool output. Therefore, the price gap often reflects that difference.
Watch for vague verbs in proposals
Read the statement of work closely. Words like “accelerates”, “supports” and “enables” describe a tool’s purpose, not a deliverable. Look instead for verbs tied to a person and an artifact, such as “reviews”, “signs off” and “documents”.
If a proposal never names a role, nobody owns the result. You can fix that during negotiation, but only if you spot it first.
What Should an Architect Review Look Like?
A proper architect review means a qualified SAP architect or specialist checks every AI output before it reaches you. The reviewer should have authority to reject results, and you should see evidence of that review in your deliverables.
2iSolutions states that every AI service is reviewed by an SAP architect or specialist before delivery. That is the standard to hold any partner to. Here are the questions that separate real review from a line on a slide.
- Who reviews the output, and what is their SAP background?
- Do they review all of it or only a sample?
- What happens when the reviewer disagrees with the tool?
- Can you see a log of changes the reviewer made?
- Does the same person stay on your engagement?
Pay attention to question two. Sampling is cheap and common. However, full review costs more and catches the edge cases that cause go-live defects.
Ask about reviewer capacity
An architect who reviews six clients at once cannot give yours real attention. Ask how many engagements each reviewer carries. Ask what happens when volume spikes near a release window.
Partners that hesitate here usually rely on the tool more than they admit. Partners that answer with specifics have thought about it.
Test the reviewer directly
Request a short call with the person who would review your work. Give them a realistic scenario, such as a custom pricing exit that reads customer group data. Then listen to how they reason.
A strong reviewer asks about business rules first. A weak one talks about the tool. Consequently, you will learn more in twenty minutes than from a forty-page proposal.
How Do You Verify Parity Between Old and New?
Parity evidence proves that converted code, forms and reports behave the same as the originals. You should receive regression results, side-by-side comparisons and a record of every difference found. Without that, you only have the partner’s word.
Parity is where AI claims either hold up or fall apart. A converted program that compiles is not a converted program that works. The numbers must match, the output must match and the edge cases must match. To see how the vendor side frames new AI capabilities, review SAP Sapphire innovation announcements and then ask each bidder which of those features they have actually validated in delivery.
2iSolutions describes full regression on every release and validation of every form against the original. Ask every bidder for the same. Then ask how they define a pass.
What parity evidence should include
Insist on specific artifacts rather than a summary slide. A credible package contains:
- Test cases tied to each converted object
- Input data sets used for both old and new runs
- Output comparisons with differences highlighted
- A defect log showing what failed and how the team fixed it
- Sign-off from a named reviewer
If a partner offers only a pass rate, ask for the underlying cases. A pass rate with no cases is a claim, not evidence.
Forms and reports deserve extra attention
Finance and operations teams feel form defects first. An invoice with a shifted tax line or a delivery note with a missing field reaches customers within hours of go-live. Canadian businesses also handle bilingual output and provincial tax rules, so layout and logic both matter.
Ask how the partner validates every form, not a sample. Ask who approves the final layout. Business users should see the output before the architect signs off, because they spot problems no test script predicts.
Which Questions Reveal Scope Limits and Unconvertible Code?
Scope limits mark what a partner will not automate or cannot convert. Every honest provider has some. Ask for a written list of code types that need manual rework, and treat a refusal to name any as a warning sign.
No tool converts everything. Some custom code relies on database tricks, direct table access or obsolete function modules. Some depends on interfaces that the target system no longer supports. Therefore, a partner who claims full automation has either not looked closely or is not telling you.
Ask these questions early:
- Which custom code categories do you convert automatically?
- Which categories need manual rework, and who does that work?
- How do you estimate manual effort before you start?
- What happens to code you cannot convert?
- Who decides whether to rewrite, retire or replace it?
The fourth and fifth questions matter most. Unconvertible code does not vanish. Someone must rebuild it, remove it or redesign the process around it.
Retire before you convert
Many custom programs serve no one. Usage data often shows that a large share of custom objects never run. Converting dead code wastes money and adds risk to your new system.
A good partner starts with a usage analysis and a retirement recommendation. You then convert only what the business needs. As a result, this step shortens the project and cuts the review burden.
Check the commercial terms around limits
Scope limits become budget surprises when the contract is silent. Ask how change requests work when manual rework exceeds the estimate. Ask whether the partner caps effort or bills by time.
Your finance team will thank you for clarity here. Fixed estimates with defined exclusions beat open-ended promises every time.
How Should You Judge an SAP Implementation Partner for Your Migration?
Judge a partner by evidence of method, named people and honest limits, not by tool names. The best SAP Implementation Partner shows how AI supports experienced consultants, explains where it fails and commits to results in writing.
Canadian buyers face a few extra checks. Data residency matters when AI tools process your code and configuration. Ask where the tool runs, who can access your data and whether the partner retains copies after the project ends.
Also ask about Canadian delivery capacity. A partner with consultants in your time zone resolves issues faster during cutover weekends. Talent in this market is tight, so confirm that the team in the proposal is the team that shows up.
Build a simple scorecard
Turn your questions into a scorecard so each bidder faces the same test. Weight the categories that carry the most risk for you. A typical set looks like this:
- Architect review depth and reviewer capacity
- Parity evidence and regression practice
- Honesty about scope limits
- Data handling and residency terms
- Named team and Canadian availability
- Commercial clarity on change requests
Score every bidder independently, then compare notes with your project sponsor. Disagreements between scorers usually point to a vague answer worth another call.
Match the partner to your project shape
A greenfield rollout asks different questions than a conversion of an existing system. Companies planning an SAP S4HANA Implementation Canada wide, with plants or branches in several provinces, need strong change management and multi-site testing. Meanwhile, a single-entity finance migration needs sharper focus on data and reporting.
Share your project shape with each bidder before they quote. Then see whether their AI services fit the work or whether they simply sell what they have.
What Does a Practical Evaluation Process Look Like?
A practical evaluation runs in four short steps: a written question set, a reviewer call, a sample deliverable and a reference check. Together they take two to three weeks and expose weak partners before contracts start.
Here is the sequence in order.
- Send the same written questions to every shortlisted partner.
- Hold a call with the proposed architect reviewer.
- Ask for a sample deliverable with client details removed.
- Speak with a reference who ran a similar project.
The sample deliverable is your best filter. It shows the format of parity evidence, the detail of review notes and the honesty of the defect log. A partner who cannot produce one has probably not done this at scale.
Prepare your own side
Buyers sometimes blame partners for delays they cause. Gather your system inventory, your custom code list and your business process owners before you start. Then name an internal decision maker who can approve retire-or-convert calls within days.
Good preparation speeds up any plan for an SAP S/4hana Implementation. It also makes AI tools more useful, because clean inputs produce cleaner outputs.
Read the contract for AI-specific terms
Add clauses that cover review obligations, evidence delivery and data handling. State that the partner must deliver parity evidence at each release. Finally, state that AI output never goes to production without named reviewer sign-off.
These clauses cost nothing to request. A confident partner accepts them, while a nervous one pushes back, and that reaction tells you plenty.
Frequently Asked Questions
Q. How can I tell whether a partner really reviews AI output?
A. Ask for a sample review log and a call with the reviewer. Real review leaves a trail of rejected results, edits and sign-offs. 2iSolutions states that an SAP architect or specialist reviews every AI service before delivery.
Q. Should I avoid partners that use AI on my migration?
A. No. AI helps with analysis and repetitive conversion work. The risk lies in unreviewed output, so focus on review depth and parity evidence rather than on whether AI appears in the proposal.
Q. What code can AI tools not convert automatically?
A. Code that uses obsolete function modules, direct table access or unsupported interfaces often needs manual rework. Ask each bidder for a written list of these categories. The answer shows how honest the partner is.
Q. How long should evaluating partners take?
A. Plan two to three weeks for a shortlist of three or four firms. That covers written questions, a reviewer call, a sample deliverable and one reference check each. Rushing this step usually costs more later.
Q. Does data residency matter for AI-assisted work?
A. Yes. AI tools may process your custom code and configuration, so you need to know where they run and who can access the data. Put retention and deletion terms in the contract.
Turning Good Questions into a Confident Partner Choice
Strong partner selection comes down to evidence you can inspect. Architect review, parity records, honest scope limits and clear contract terms tell you more than any demo. Each question in this guide exists to move a vague claim into a document you can check.
The buyers who get the best results treat AI as a tool inside a managed service. They ask who owns the outcome, how the partner proves equivalence and what happens to code that no tool can handle. Partners who welcome those questions usually deliver well.
2iSolutions designs its AI-assisted services around architect review and full regression, so bring your toughest questions and test the answers against this list.
Email us at info@2isolutions.com to book a free assessment.
