Stage 1 - Export Analysis¶
The Export Analyzer is the first step to understanding the Export file. It interrogates the whole file to answer the questions: what is in the file, and what does it do?
It runs directly after extraction, and examines everything in the /extracted folder where the complete Export file content has been extracted. It treats the export as one body of work rather than a set of separate integrations. No other processes can start until the Export Analyzer has finished, because every Stage after it builds from the list of integrations it produces.
What this stage produces¶
The Export Analyzer produces two key deliverables:
The Export Analysis document
The list of all integrations present in the Export file
The Export Analysis document is written into the /extracted folder in the Project Tree, alongside the extracted files, and its name carries the Project name and the date and time of the run. There is only ever one of them in a Project.
It is a long document and it is organized as ten numbered sections and an appendix:
An executive summary. Two or three paragraphs on what the export contains, with high level analysis of the file content: the platform and how confident SLIM is about that identification, the total number of integrations, how many are simple, medium and complex, how many external systems feed in and out, and how many shared components were found. It closes with an overall complexity rating and a recommended modernization approach.
What was unpacked. A record of the archives extracted, including archives found inside archives, and any files that had to be rewritten into a readable format before they could be analyzed.
Platform identification. Which source platform this export came from, with the evidence for that conclusion and any platform-specific notes.
The integration inventory. The part most readers turn to first: A count by category - inbound, outbound, orchestration, scheduled and event-driven - and then the complete list, one row per integration, each with its category, its complexity, and a short description of what it does.
Source systems and target systems, each summarized and then listed in detail: what the integrations read from, and what they write to.
Common components. The schemas, transformations, code libraries and configurations used by more than one integration, ranked by how many depend on them. Anything used by five or more is flagged critical, and those are the pieces that break the most if they are handled badly.
Dependencies. Which integrations are entry points, which are called by others, and which sit in the middle. This section carries the diagrams: an integration hierarchy, a system dependency map, a call matrix, and the dependency chains that matter most.
Modernization considerations. A suggested order of work, the challenges SLIM expects, a mapping from each source technology to its SnapLogic equivalent, and a risk assessment.
Next steps. Immediate actions, open questions to resolve with the customer, and the further documentation the work will need. This is the section where the gaps in the export surface as questions rather than as assumptions. Close them out early: every one you leave open is ambiguity that later Stages will resolve on your behalf, and they will not tell you they did.
Complexity, where the document uses the word, is a count of moving parts rather than a judgment: roughly, one to three components in a single flow is simple, four to seven with some branching is medium, and eight or more with multiple flows and error handling is complex.
The second deliverable this Stage produces is the list of integrations that every later Stage works from: this is the list you see on the Job Status page, and the list you tick on the Integration Analysis and Pipeline Generation pages. SLIM builds it here and orders it by dependency, so that integrations nothing else relies on come first and the ones that call others come later. Any empty folders, packaging metadata, or files from the operating system are omitted from the list deliberately.
What this Stage does not do is introspect into any single integration in depth. It tells you an integration exists, what category it falls into and roughly how complex it looks. Working out what an integration actually does, step by step, is the next Stage of the modernization process: Stage 2 - Integration Analysis.
Running it¶
The Export Analyzer needs an extracted export, and the Extracted Assets panel on the Export Analysis Stage page is where you confirm you have one. It lists what was unpacked, with a count. If it reads No extracted assets, with Extract assets prior to running the analysis, then extraction has not run yet and the Go to Project button takes you back to the Project Home Page to do it - see Uploading an Export. If there is no Export file in the Project at all, the run control is replaced by Upload files first.
Before you start the Export Analyzer, look at the Export Analysis Prompt panel: Anything you enter in this pane shapes this Stage and no other. As every subsequent Stage in the process builds from the Export Analysis, this is the moment it is cheapest to add guidance to focus the modernization, so nothing unnecessary is analyzed and taken forward. The section below includes suggestions of what might be helpful to include here.
Next, click Run Export Analyzer. In Automatic Mode you never press it: extraction continues straight into this Stage - see Choosing an Execution Mode.
While it runs, the Activity Log streams what SLIM is doing, and a Stop button is available. Expect to see Activity Log entries related to reading the export, deciding which platform is the source of the Export file, walking the files, and then starting to write the Export Analysis document.
SLIM sizes the work to the export. On a large export it takes extra passes to keep a very big file set manageable; on a small one it visibly skips passes it does not need, and says so in the log. A single small file with one flow in it will go through in a fraction of the time and skip most of the heavy work. That is correct behavior, not a shortcut, and it is not a sign that anything was missed.
When it finishes, the Stage header shows a pill labeled Complete, sometimes with how long the run took and what it cost, and a panel appears at the top of the page: Export Analysis complete, with Continue to Integration Analysis.
One caution on watching progress: the Job Status page does not refresh itself, and what it reports is read from the deliverables already written into the Project rather than tracked while the work is happening. So it can still say a run is in progress after the document has been written. Reload the screen, or follow the Activity Log instead - see Monitoring Progress.
Reading the result¶
There are three places to read the document, and they do different things.
The Job Status page. The Export Analysis button opens the document in the viewer beside the integration list. It is the quickest look, and it is read-only: there is nothing to download from here. The expand control in the viewer header hands the whole working area to the document, hiding the list and the page heading, and becomes a collapse control to put the page back.
The Integration Analysis Stage Page. The document appears there in a panel headed with its file name and (from Export Analysis). This is the only place you can modify the document contents: Edit to correct it in place, Download for Markdown (.md) or PDF (.pdf), and an expand control that gives the document the whole working area.
The Project Tree, under /extracted, on the Project Home Page. Clicking the document opens it in the preview pane beside the tree, and because it is a Markdown document that pane offers a Download button with the same two formats: Markdown (.md) or PDF (.pdf). The download icon on the document’s own row in the tree skips the choice and saves the Markdown file as it stands. The icon on a folder row saves that whole folder as a ZIP archive, which is the quickest way to take the analysis away with everything it was written from.
It may be a surprise that a document produced by Stage 1 is edited on Stage 2’s page. The rule behind it is consistent across SLIM: a document is edited where it is consumed, and Integration Analysis is the Stage that reads the Export Analysis.
If you do modify the document, remember to Save before you navigate away; if you do not, any unsaved changes are lost.
Read the Export Analysis completely before moving forward to the next Stage. Four questions are worth asking every time:
Is it accurate?
Is anything missing - an integration, a system, a dependency you know exists?
What questions does it raise that only the customer can answer? There usually are some, and the document lists them.
What further documentation does this work need?
NOTE: As with all deliverables from SLIM, this document was generated with the use of AI tools, and generated output looks right whether or not it is right. Check the contents against what you and your other stakeholders know. Correcting it here costs almost nothing; a misunderstanding carried forward gets more expensive the further along the process it gets. See Verifying the Output.
Two things in particular to fix before you share the Export Analysis:
The suggested order of work is presented in weeks: foundation in weeks one and two, quick wins in weeks three and four, and so on. Those ranges are a template, not an estimate for this particular estate. Either replace them with real dates or excise them.
The Next steps section describes running each integration from a command line. That is not how you will do it with SLIM: everything is directed through the web application, and it will confuse a stakeholder reading the PDF. Edit it to describe the Stages in the application, or delete it.
Deciding what is in scope¶
After the Export Analysis has been generated, you should have enough information to make scoping decisions. The document supports the discussion with stakeholders about which contents of the Export file need to be carried forward, and which, if any, can be retired from use. Export files typically arrive fuller than the work: analyzing the whole of one in depth costs a great deal of time and money, and some of what it costs will be spent describing integrations nobody intends to keep.
You have two levers, at two different points:
Here, with instructions. Add to the Export Analysis Prompt panel and re-run: name the integrations, folders or naming patterns that matter, and tell SLIM to disregard the rest. Do that and the inventory itself comes back narrowed, which means everything downstream is narrowed too.
At the next Stage, by selection. The Integration Analysis page lists what was found with a checkbox against each one. Tick the ones you want and save the selection - if you do not save it, the selection is ignored.
Use both techniques to refine the Project scope: instructions are the stronger lever, because they change what gets analyzed and written in the first place; selection is the finer one, and you can change it between runs. Narrowing the Scope works through the choice properly.
Why this document is worth the care¶
It is often the first accurate description of the integration estate that some users have had: Integrations get inherited through organizational restructuring, natural attrition of the original authors, and what remains can be limited to a break-fix relationship: the owning team may know how to patch the integrations to keep them running, but not much more.
A document that clearly describes what each integration does, what it touches and how complicated it is changes what that team can decide, including the question underneath the whole Project: whether a given integration needs to move forward at all.
For these reasons it is worth reading the Export Analysis closely, correcting where it is wrong, and getting it signed off as accurate by stakeholders. The PDF download exists to support that process - see Sharing Results for Approval.
Adjusting and re-running¶
Instructions for refining this Stage are entered in the Export Analysis Prompt panel on the Stage Page. Click the Edit button, type the changes (in markdown format, if formatting is needed), and Save the updates. They apply to this Stage only and will not affect any other; guidance meant for the whole Project belongs in the Global Prompt on the Project Home Page instead - see Creating a Project. When empty, the panel reads No step-specific instructions - click Edit to add some.
Examples for additional instructions to add, include:
Guidance to narrow the scope of the Export file: to focus on specific integrations, and ignore everything else,
Changes to the document language and tone to target a different audience demographic and adjustment of the level of technical detail,
The arrangement of the standard document sections: with some material moved into an appendix, or another section dropped that is not useful in the wider Project context.
Refining Instructions covers how to write instructions that work.
Then re-run the Export Analyzer. The control on a completed Stage is relabeled as Re-run, and it asks first: Re-run export analysis? This will overwrite existing results. Take that literally:
The previous document is deleted, not kept alongside a new version. SLIM removes the old Export Analysis document before writing the new one, so a Project only ever holds the latest. If you want to compare the two, download the current one first. There is no other copy.
Your edits go with it. A re-run regenerates the document from the export, so anything you corrected by hand is overwritten. Download your edited version before re-running, and either re-apply the corrections or fold them into your instructions so the next run gets them right by itself.
A saved integration selection is lost. Re-running rebuilds the integration list, and a rebuilt list starts with everything selected. Go back to the Integration Analysis page and set your selection again.
If a run fails, the executing button is labeled Retry rather than Re-run. If you stopped it, it is labeled Re-run. Either way the same overwrite applies. See Stopping and Restarting.
This stage runs once per export¶
By default you run this Stage once per Export file, and then you are done with it.
It is the one Stage that looks at the export as a whole, which is why there is only one document and why that document is replaced rather than added to. Every Stage after it works at the individual integration level: Integration Analysis runs once per integration you select, Pipeline Generation once per integration again. That difference shows on the page itself - there is no integration list here, because at this point SLIM does not yet know what the integrations are.
Run it again when something has genuinely changed:
you have narrowed or widened the scope in the instructions,
you want a different audience, level of detail or structure,
the first run got the platform or the inventory wrong, or
the export itself has been replaced.
That last case is different in kind. Replacing the Export file clears the analysis documents and generated assets and restarts the Project from the beginning - see Uploading an Export. Re-running this Stage repeats one Stage; replacing the export resets the Project.