When Should You Migrate From Packaged Software / SaaS to a Custom System? 5 Signals, Hidden Costs, and a Zero-Downtime 6-Month Playbook

"Our packaged system costs NT$30K a month — nearly two million over five years — and we still cannot add a single custom field." That is what a trading-company owner of 12 years told us. He was not trying to save the monthly fee; he was stuck: reports would not come out the way he needed, connecting his own warehouse cost extra, and even taking his data out came with an export fee. This piece is about exactly that situation — when to migrate from packaged software / SaaS to a custom system, where the hidden costs are, and how to move house without downtime.

Myths to Break

Myth 1: SaaS is always cheaper than custom. Reality: short term yes, long term not necessarily. When monthly fee x seats x years plus the add-on modules you are forced to buy exceeds a one-time custom build, total cost of ownership often flips.
Myth 2: switching means downtime and scrambled data. Reality: with dual-write plus parallel run, the old system keeps running while the new one is validated in sync, and cutover is nearly imperceptible.
Myth 3: custom means rewriting everything from scratch. Reality: the mature approach is keep the 80% that works, customize only the 20% that blocks you — not rip and replace.
Myth 4: the data is mine, I can move it anytime. Reality: many SaaS only give you exportable fields; relations, history, and attachments often come out incomplete — negotiate this at signing.

Core Framework: Five Signals to Switch

Do not switch out of annoyance. Score these five signals; only if three or more hit is migration worth serious evaluation:

Cost crossover: three-year SaaS total > custom build + three years of ops.
Process hostage: you change your operations to fit the software, not the other way around.
Integration pain: the systems you want to connect (warehouse, payments, LINE, accounting) are either impossible or priced sky-high.
Data trapped: you cannot get the report dimensions you need, or export is restricted.
Scale ceiling: growth in users/data spikes the fee, or performance starts buckling.

Three Typical Scenarios Compared

Company	Current state	Recommendation
10-person e-commerce (< NT$1M/mo revenue)	Shopify / packaged cart	Do not switch yet. At small scale SaaS convenience far outweighs lock-in; spend on marketing.
50-person trader (multi-warehouse, multi-currency)	Locked into packaged ERP, NT$30K/mo	Worth a hybrid: keep the accounting module, customize the 20% of orders and warehousing.
150-person services (many branches, millions of members)	SaaS performance and cut both squeezing	Usually should go custom; three-year cost and control both favor it, but move via parallel run.

Full Hidden-Cost Checklist

Data migration hours: cleaning, field mapping, validation — often 15%-25% of the project, NT$80K-300K.
Parallel-run double cost: 1-2 months of both systems running before cutover means paying twice short term.
Retraining cost: staff hours to learn the new system and a short-term efficiency dip — do not pretend it is zero.
Integration dev: payments (ECPay about 2.75%-3.5%), e-invoicing, logistics APIs each take hours.
SEO/GEO preservation: if a website move is involved, botched 301 redirects and structured data lose rankings (see Google's migration guidance).
Ops reserve: budget 15%-20% of dev cost per year for maintenance after go-live.

Vendor KPI Scorecard (Migration-Specific)

☐ Did they propose a concrete no-downtime / parallel-run migration plan?
☐ Does data migration include cleaning, mapping, validation, and sample sign-off?
☐ Are they willing to run a small-scope Pilot before full volume?
☐ Is source code and IP clearly assigned to you?
☐ Do they deliver full handover docs and an environment (a new hire runs it in an hour)?
☐ Is there a rollback plan if cutover fails?
☐ Does the quote itemize migration, integration, and training separately?
☐ Do they offer a post-launch ops SLA and response time?
☐ Can they show a similar-scale migration case or reference?
☐ Will they honestly say your situation should not migrate yet?

ScriptWalker's Options and When Not to Use Us

We offer four models: one-off migration project (data move and integration), monthly retainer (post-launch ops and iteration), advisory (we evaluate and supervise; you hire the build), and full managed (long-term custody of the system). But we will honestly talk you out of these cases:

Still small, where SaaS lock-in cost is below its convenience value — do not move yet.
Just friction with the current vendor and no substantive change in needs — swap the vendor, not the architecture.
No internal point person to help with acceptance and data confirmation — migration will fail; staff up first.
Expecting move-once, zero-maintenance forever — a custom system still needs ongoing ops.

Transition Playbook (6 Months)

Month 1: inventory the current state, test data export, confirm movable vs not, define success metrics and rollback conditions.
Months 2-3: build core custom features, create data mapping and cleaning scripts, run a small Pilot.
Month 4: dual-write parallel run — old system keeps running, new one takes data in sync with daily reconciliation.
Month 5: cut over module by module (low-risk first, core last), keeping rollback available at all times.
Month 6 / 90-day review: shut down the old system, verify performance and cost, and settle the actual payback period.

Decision Checklist (SaaS to Custom?)

☐ Is three-year SaaS total higher than custom + ops?
☐ Do I often change my process to fit the software?
☐ Are the systems I want to connect impossible or priced sky-high?
☐ Can I not get the report dimensions I need?
☐ Can my data be fully exported (with relations and attachments)?
☐ Do I have an internal point person for migration acceptance?
☐ Can I absorb 1-2 months of parallel-run double cost?
☐ Am I ready to budget for ops every year?
☐ Is this pain an architecture problem, not just a vendor problem?
☐ Do I have a clear payback expectation?

FAQ

Will migration stall my business?

With parallel run and module-by-module cutover, normally it is nearly imperceptible. The real risk is not technical — it is skipping data validation and a rollback plan, both of which we prepare first.

Can I take all my data out of the old SaaS?

You can take the exportable parts, but relations, history, and attachments are often incomplete. We run an export test in month one and lay out what cannot be retrieved so you decide early, not mid-move.

Do I have to migrate everything at once?

No, and we advise against it. Move low-risk modules first, validate, then move the core — lowest risk.

How long to pay back?

Depends on scale. For 50-plus staff with high fees and integration blocks, 12-24 months is common; we compute it clearly at the evaluation stage and will say so if it is not worth it.

Call to Action

Not sure whether to move, or whether moving makes things worse? Tell us your current system, monthly fee, and three biggest pain points. ScriptWalker offers a free 30-minute migration assessment to run three-year total cost vs custom on your real numbers — and if it is not worth it, we will tell you straight not to move.