ARCXA
For systems integrators and migration delivery teams
ARCXA is data migration software. Map source fields, review the rules and trace values into the target before deciding what to accept.
Six synthetic customers. One missing required email. Work through Discover, Map, Review, Prove and Reuse in a local sample.
Uses bundled synthetic records only.
Illustrative migration model
Source
Inspect what exists
Mapping + rules
Make meaning explicit
Target
Preview, then check
From review: required value missing? Hold for review.
Held exception
Keep the original record and the reason. An exception still needs an owner.
Source fields connect to selected mappings and preservation rules. Review determines which records can proceed to a target preview and checks. A missing required value takes a separate held branch, retaining the original and reason. This illustration shows a process, not an execution result.
Sample
Discover, Map, Review, Prove, Reuse. Inspect six synthetic customer records, connect five fields, decide how to handle the missing required email, then validate and inspect the local calculation.
Browser simulation. Synthetic data. Not an ARCXA runtime.
Discover → Map → Review → Prove → Reuse. Profile six synthetic customers, assign five fields, resolve one missing email, then validate and run your local plan.
The sample needs JavaScript. The field guide, lesson transcripts, and FAQ remain available without it.
Workflow
Discover, Map, Review, Prove, Reuse. Each stage carries a decision into the next. A field association says where a value goes; source context and human review establish what it means. Moving records alone does not establish acceptance.
Inspect your source
Profile the extract against target requirements. Inspect fields, missing values and identity before choosing any rules.
Carry forward
A source profile and a list of target requirements to resolve.
Connect the fields
Assign source fields to target fields. Check the meaning as well as the label: IDs remain text, ISO dates and full status words retain their representation.
Carry forward
A mapping plan with explicit preservation rules and a before/after preview.
Resolve the exception
Inspect Cedar Studio’s missing required email. Choose to hold the original for review or leave the issue unresolved. A hold does not repair the value.
Carry forward
An exception decision, its reason and an original record retained for review.
Validate, approve and run
Check the current mappings, identity, required-value decisions and record accounting. Acknowledge the current revision before running the local sample; compare its evidence afterward.
Carry forward
Current checks and a reviewed local result to compare with the source.
Inspect and keep the plan
Keep the selected rules, field traces and held reasons as a planning artifact. For another rehearsal, check source meaning and target requirements again before approval.
Carry forward
A reviewable plan for the next rehearsal, with fresh validation still required.
The operator prepares and checks the migration. The acceptance owner decides whether the evidence meets the agreed requirements. Name both before an evaluation.
Evidence
Read source, selected rule, target preview and check together. A plausible target value needs a traceable rule and a comparison with the original. Review the held branch with the same care as the records that proceed.
Illustrative field lineage
Source field
customer_no
“00041”
Original identity as text.
Selected rule
Preserve text
No numeric conversion
Associate the field without changing its representation.
Target preview
customer_id
“00041”
An illustrative preview, not a written record.
Check
Compare identity
Exact text + uniqueness
Compare source and target; check for duplicate identities.
Separate held branch
contact_email: nullTeaching excerpt: customer_no as text “00041” follows a preserve-text rule to the customer_id preview “00041”. Check exact representation and uniqueness. Separately, a missing required contact_email can be held with its original null and reason; it is not a repaired email or a target write. No checks have run in this static illustration.
Acceptance asks more than “did it move?” Compare identity and values, account for every record, inspect exceptions and agree who signs off. A browser sample cannot establish acceptance for your systems.
Any file saved from the sample is a local sample planning artifact. It is not a signed, native or authenticated ARCXA packet.
Run a reviewed sample to inspect its source, rule, target, and check values here. A current result enables both JSON downloads.
Learn
A question, a review decision and its consequence. These static storyboards use teaching excerpts from the synthetic example. Read each full HTML transcript without starting the sample.
Illustrative storyboard
If every row is accounted for, is every customer ready?
Before
6 source records
Cedar Studio has contact_email: null.
Decision
Hold for review
Keep the original and the missing-email reason.
After
5 transformed + 1 held
Expected only after holding, validation and an approved run.
Start with the question: does accounting for all six source records make all six customers ready for the target? Cedar Studio has no contact email, while the illustrative target requires one. A matching total does not answer whether each record meets that requirement. Inspect the missing value and its disposition alongside the counts.
The review decision is to hold Cedar Studio for review. Preserve the original record, including the null email, and the reason: missing required email address. Do not invent a replacement address, delete the customer or describe the hold as a repair. Leaving the issue unresolved blocks the sample; holding it creates an explicit disposition that can be checked.
After the hold, current validation and an approved run, the expected sample accounting is five transformed, one held and none discarded. That is an expectation illustrated here, not a result calculated by this storyboard. Open the sample evidence to inspect actual current counts and values. An acceptance owner still needs to decide how the exception will be handled in an authorized evaluation.
Illustrative storyboard
Would “41” mean the same thing as the identifier “00041”?
Before
“00041”
An identifier stored as text.
Decision
Keep text
Numeric conversion would produce 41.
After
“00041”
Preserve the exact representation in customer_id.
Look at the identifier “00041”. A number conversion would produce 41. The digits may appear to refer to the same quantity, but a customer identifier is not a quantity. Its original text representation is part of the value being carried between systems. A familiar target field name cannot establish permission to remove leading zeros.
The decision in this guided example is to associate customer_no with customer_id and preserve text unchanged. Compare the original and target preview directly, then check identity uniqueness across the records. The date values already use ISO representation and the statuses are full words; the sample preserves those too. No ambiguous date interpretation or abbreviated status glossary is introduced here.
The expected target representation remains “00041”. This storyboard illustrates the preservation rule; it does not run a numeric-conversion experiment. In the sample, inspect the chosen field associations and the resulting trace. In a real evaluation, have the acceptance owner agree the identity requirement and compare output with the source independently before accepting it.
Illustrative storyboard
The preview looks right. Which rule put that value there?
Before
customer_no
A target value alone cannot explain its origin.
Decision
Trace the field
Read source, selected rule, target and check together.
After
Evidence to compare
Keep the rule revision and inspect held originals too.
A target preview can look plausible without showing where it came from. Start with customer_no and ask which association and preservation rule led to customer_id. Read the original value, selected rule, target preview and check in one chain. A field trace makes the explanation inspectable rather than asking a reviewer to trust the appearance of a result.
The review decision is to compare the field evidence for the current rule revision. Inspect exact identity text and required values, then account separately for transformed, held and discarded records. For a held customer, inspect the retained original and the reason instead of implying that the preview was loaded. If mappings or exception decisions change, validate and approve the changed revision before treating a new result as current.
Keep the local JSON as a sample planning artifact for discussing another rehearsal. It describes the browser calculation, not a database write or an authenticated ARCXA packet. For software evaluation, agree acceptance criteria with the owner, verify the actual release and operations, and compare output independently. Reusing a plan does not carry approval into a different source or target.
Fit
Start with a gap you can name: repeated mapping decisions, unclear exceptions or evidence that is hard to review. Compare ARCXA with the SQL, ETL, tests and tickets you already use. Define a bounded evaluation before choosing a delivery path.
Next step
Software assessment and delivery help are separate conversations. The outlines below describe what each one covers. Nothing on this page sends a request or books a meeting.
For teams assessing the software itself.
For teams looking for delivery help, discussed separately from the software evaluation.
No form, email route or booking link is connected on this page.
FAQ
No. The sample computes a fixed synthetic fixture in your browser. It connects to no database and produces no native signed packet.
No. The page accepts no uploads or credentials. Keep confidential records out of it.
No. Prewritten mappings and deterministic calculations drive the sample. Optional model-assisted suggestions are separate; evaluate the actual review and execution controls independently.
No. Verify the selected release and the exact extraction, transformation, loading and validation operations you need, with independent checks of the output.
No. The inspected public version uses the Business Source License 1.1. Evaluation and production terms differ, so check the selected version and the approved offer.