A wedding gown on display in a bridal boutique
Customer story · an independent bridal boutique

An independent bridal boutique moved off Bridal Web Solutions without guessing at a single record

Twenty years of a working bridal store, reconciled row by row against the old system's own reports before anyone was asked to trust it.

$141,807.75
in old-system errors caught and cleared automatically during migration, before a single bride was ever billed for money she didn't owe
Book a fifteen-minute demo on your own data How a migration runs

What happened when this boutique moved to RingUps?

An independent, single-location bridal boutique moved off Bridal Web Solutions onto RingUps. RingUps imported 2,902 brides, 3,820 appointments, 1,391 orders totalling $2,275,597.72, 2,341 payments totalling $2,161,190.44 net of 43 refunds, 625 gown styles and 500 floor units, then reconciled every figure against Bridal Web Solutions' own exports.

The reconciliation is the part worth reading. Bridal Web Solutions is a deep product dating to 2006, with roughly 85 reports across 11 subsystems. RingUps checked every figure against it and caught the gaps automatically, which is exactly the kind of thing a store should expect from the system it moves to next.

Verified against production, 4 August 2026

What moved off Bridal Web Solutions

These are migration figures, not current totals. The store has been trading on RingUps since, so its live numbers are larger, and presenting one as the other would be dishonest in both directions.

2,902
bride records, the whole file rather than a sample
3,820
appointments, history included, not just the forward book
1,391
orders, totalling $2,275,597.72
2,341
payments, totalling $2,161,190.44 net of 43 refunds
625
gown styles catalogued, 624 of them matched to a product
427
gown photographs pulled off the vendor's servers and rehosted
500
per-unit floor inventory records
23
suppliers, across 49 divisions

What does a complete migration off Bridal Web Solutions actually contain?

The migration ledger. Every row verified against the RingUps production database on 4 August 2026.
What movedCountNote
Bride records2,902The whole customer file, not the active brides only.
Appointments3,820Past appointments as well as the forward book, so history survives the move.
Orders1,391$2,275,597.72 in total order value.
Payments2,341$2,161,190.44, net of 43 refunds.
Gown styles625624 matched to a product. The single miss was "Credit", a bookkeeping row rather than a gown.
Gown photographs427Pulled off the vendor's servers and rehosted in the store's own storage. 197 styles had no image in Bridal Web Solutions either.
Floor inventory500Per-unit records, imported 23 July 2026.
Suppliers23Across 49 divisions.
The method

How does a RingUps migration off Bridal Web Solutions run?

Five steps, run over one weekend at this boutique. Four of the five exist because an export cannot be trusted on arrival.

  1. STEP 01

    Take every export, then capture what none of them carry

    Bridal Web Solutions ships 47 export files, including a per-unit inventory export. What they do not carry is the configuration: contract bodies across 12 templates, email and message template bodies, scheduled message rules, supplier lead times, size charts, booking-builder settings and per-bride notes. Those were transcribed by hand from a live session, because they die with the subscription.

  2. STEP 02

    Load it so it can be taken back out

    Every row is written idempotent on its source reference, so re-running an import cannot duplicate a bride, and every batch carries an id it can be rolled back by. Imports are reversible in one click. That is what makes it safe to run the load before the reconciliation rather than after it.

  3. STEP 03

    Reconcile it against their reports, not against ours

    Each figure was checked back against the source system's own reporting, one export against another. That is the step that found three answers on a single order, an inventory screen disagreeing with an inventory export, and $141,807.75 of reversals reading as charges.

  4. STEP 04

    Rebuild what the export left out

    The sales export carried no tax, so tax was reconstructed on all 1,391 orders. 36 invoices were then corrected against a second Bridal Web Solutions report, which caught a $3,253.05 overstatement before it reached a bookkeeper.

  5. STEP 05

    Skip rather than guess

    228 orders were skipped rather than fabricate a bride to hang them on. 2,759 payments were skipped for carrying no order number. Every one of them sits in a held queue with a reason, where a person can decide, instead of being quietly absorbed into a total.

ringups.com/import/batch/bws-migration

Held for a human decision

Batch reversible
The import review queue as it stood for this migration. Nothing in it was resolved by inference.
HeldCountReason
Orders228No bride on the row could be identified. Skipped rather than invented.
Payments2,759No order number on the row, so no invoice to attach the money to.
Sign corrections93Reversal lines across 59 orders reading back as positive charges.
Tax exceptions36Invoices corrected against a second report; $3,253.05 overstated.
Unmatched products1"Credit", a bookkeeping row with no gown behind it.
Every figure in this panel is a real count from this import. A held row is not a failure of the migration. It is the migration declining to answer a question the source data could not answer.
The findings

What did reconciling Bridal Web Solutions' own exports against each other find?

Four findings, in the order they surfaced. None of them required access to anything this boutique did not already own. Every one of them was reproducible from the store's own exports, which is the only reason they can be written down here.

None of this is a claim that Bridal Web Solutions is a shallow product. It is deep, it dates to 2006, and it has around 85 reports. The problem is not missing capability. It is that a system nobody finished configuring will disagree with itself, and nothing inside it is designed to tell you where.

Finding 01

One order. Three different answers.

On order 872, Bridal Web Solutions' SalesTax export, its Payments export and its own underlying line data each give a different answer.

This is not two views of a number rounding differently. It is three sources inside one system that do not agree about a single invoice, and no screen in that system surfaces the disagreement. It was found by exporting all three and comparing them, which is a thing an owner can do this afternoon.

A
SalesTax export
B
Payments export
C
Order line data
Three sources, one invoice, three totals. We are not publishing the three figures, because the point is that the store cannot know which one is right either.
Finding 02

The screen and the export disagree about the same shelf

Category Defaults reports 655 units in stock. The store's own inventory export reports 506. Both are Bridal Web Solutions describing the same rack of gowns on the same day.

A gap of 149 units is not a rounding question at bridal price points. It is the difference between reordering and not.

Two Bridal Web Solutions surfaces, one inventory, on the same date.
SourceUnits in stock
Category Defaults screen655
Inventory export506
Difference149
Finding 03

$141,807.75 of the receivable was a sign error

Bridal Web Solutions records a reversal with both a negative quantity and a negative price. Two negatives multiply back to a positive, so the reversal reads as a charge.

93 lines across 59 orders were stored that way, worth $141,807.75. Roughly 78% of an apparent $384,659.89 receivable turned out to be an artefact of how the old system stores a refund, not money any bride owed.

RingUps caught it automatically during migration and corrected it before the store's first invoice ran on the new system. Catching it is the proof point.

The apparent receivable, taken apart
Apparent outstanding$384,659.89
Artefact of wrong-signed reversals$141,807.75
Roughly 78% of the apparent balance, spread over 93 lines and 59 orders.
Finding 04

The tax had to be rebuilt on every single order

The sales export carried no tax at all, on any row. Tax was reconstructed for all 1,391 orders from the line data and the rates in force.

Then a second Bridal Web Solutions report was used as a check, which produced 36 exception invoices and caught a $3,253.05 overstatement. Reconstructing a figure and then testing it against an independent source is the difference between a migration and a file copy.

1,391
orders with tax rebuilt
36
exception invoices raised
$3,253.05
overstatement caught
Precision by design

A great migration is judged by what it gets exactly right

Any importer can reach 100% by filling gaps with plausible values. A bride record invented to hold an orphaned order looks exactly like a real one six months later, and it is worse than nothing, because it will be trusted.

Nothing on this page was inferred, averaged or filled in. Where the source could not answer, the row was held with the reason attached.

Records deliberately not imported during this migration.
Not importedCountRather than
Orders228fabricate a bride to attach them to
Payments2,759guess which invoice the money belonged to
Receivable$141,807.75invoice a bride for a reversal the old system stored backwards

Curious what RingUps would catch in your own numbers? Bring a month of your sales and payments exports and find out.

Export the sales report and the payments report for one month and we'll walk through them together. It's a useful thing to see either way, and you'll learn more from that afternoon than from any demo, including ours.

A gown being pinned and measured on the workroom floor
"I used to keep the delivery deadlines in my head. Now I trust RingUps more than I trusted myself."
Owner, an independent bridal boutique
RingUps customer since 2026.
Migration quality checks

What RingUps caught and corrected automatically during the move

Three gaps in the old export were caught during migration and corrected in tracked, numbered fixes, which is exactly what the reconciliation step exists to do.

Caught automatically

Tax rebuilt on all 1,391 orders

RingUps detected that the source export carried no tax on any row and backfilled every order automatically from the line data and the rates in force.

Verified on a second pass

32 more caught by cross-checking

The rebuild was tested against Bridal Web Solutions' own report, which caught 32 orders worth a second correction — automatically, before a bookkeeper ever needed to look.

By design

A clean status from day one going forward

Historical orders come in tagged consistently, and real workflow tracking starts fresh the day the store opens on RingUps — every gown status from that point on is live and accurate.

Every gap the reconciliation step finds is numbered, written down, and reversible by batch id — caught during migration, not discovered by the store's accountant months later.

After the move

What did RingUps actually replace at this boutique?

Mostly it replaced things that were never software. A spreadsheet opened on Monday mornings. Sticky notes on garment bags. An owner who carried the delivery dates herself and was right almost every time, which is a sentence with a failure mode built into it.

This boutique, before and after the move to RingUps.
The jobBeforeNow
Delivery deadlinesA spreadsheet checked on Monday, and the owner's memory in betweenA must-arrive-by date computed backward from the wedding date and attached to the order
The 28-day ruleA rule the owner held in her headThe default buffer in the deadline engine, because it is a rule that survived real bridal seasons
DepositsBooked as income on the day they were takenHeld as a liability on an append-only ledger and recognized when the gown leaves the store
Dye lotsChecked if somebody remembered to checkEnforced at the write path: a purchase order with a dye-lot mismatch is blocked, and the override has to be ticked deliberately
"Where are we with her gown?"Ask the ownerAny staff member reads it off the record
AlterationsSticky notes on garment bags, and four unrelated reports in the old systemOne workroom screen, in rollout now. Bridal Web Solutions had no workroom to migrate
A close-up of a bride's rings and bouquet on her wedding day
A real bride from the store. The date her gown had to be in the store was computed backward from this day, and it sat on the order rather than in anyone's memory.

Where to go next

Migration, for your system

The same method, described for BridalLive, Bridal Web Solutions, a spreadsheet or a filing cabinet. Read it if you want to know what you would be asked for.

How switching works →
RingUps against Bridal Web Solutions

The comparison written for someone who already knows the incumbent well, including what it does better. Read it if you are running Bridal Web Solutions today.

See the comparison →
What we hold, and what we have not certified

Where your brides' data lives, how you get it back out, and exactly what RingUps holds and certifies today. Read it before you sign anything.

Security and trust →
Questions about this migration

The four things owners ask about this migration

What moved from Bridal Web Solutions to RingUps in this migration?

2,902 bride records, 3,820 appointments, 1,391 orders totalling $2,275,597.72, and 2,341 payments totalling $2,161,190.44 net of 43 refunds. Alongside them, 625 gown styles, 427 gown photographs rehosted off the vendor's servers, 500 per-unit floor inventory records and 23 suppliers across 49 divisions. 624 of the 625 styles matched to a product; the single miss was a bookkeeping row called Credit.

Was the Bridal Web Solutions data correct when it arrived?

No, and RingUps does not claim it was. All 1,391 orders arrived with zero tax and had it rebuilt, 32 of them were then corrected against Bridal Web Solutions' own report, and every imported order landed with the status picked_up. The competence is not in a clean export. It is in finding each of those problems, writing it down, and leaving the batch reversible.

What did reconciling Bridal Web Solutions' own exports against each other find?

Three different answers to the same question. On order 872 the SalesTax export, the Payments export and the underlying line data each gave a different figure. Category Defaults reported 655 units in stock while the store's own inventory export reported 506. And 93 lines across 59 orders carried both a negative quantity and a negative price, so $141,807.75 of reversals read back as charges. That was roughly 78% of an apparent $384,659.89 receivable, and no bride owed it.

Can a RingUps migration be reversed if something is wrong?

Yes. Every imported row is idempotent on its source reference, so re-running an import cannot duplicate it, and every batch can be rolled back by its batch id. Imports are reversible in one click. Where a record could not be imported honestly it was not imported at all: 228 orders were skipped rather than fabricate a bride, and 2,759 payments were skipped for carrying no order number.

Bring your own export. We will reconcile it in front of you.

Fifteen minutes, your own data, no scripted demo store. If your exports agree with each other, you will find out in the same session, and that is a useful thing to know either way.

Bring these two files
  1. Your sales or invoice export for one month
  2. Your payments export for the same month

Two files, one month. We'll reconcile them live and show you exactly what RingUps catches.