Migrate what you choose to migrate

The tier is set by scripts converted, not scripts found, and those are rarely the same number — a good deal of what sits in an account is either not yours to move or not doing anything.

What isn't counted: scripts a vendor owns and must update themselves, and scripts that turn out to be deployed to nobody. Named in the catalog with the reason, and excluded from both the work and the price.

Complexity moves you within a tier, not between them. An unusually gnarly estate costs more at the same count, and I'll tell you that from the catalog before you commit rather than after. Risk doesn't affect price at all — it decides the order things get done in, highest exposure first.

Everyone starts at $2,000, no matter which tier you eventually end up at

That buys the catalog and the first tier of conversions. Once you've seen what you're actually carrying — which of it is yours, which is live, which is blocked — you decide how far to go, and pay the difference to move up a tier.

There's a reason it works that way round. You can't sensibly choose how many scripts to migrate before you know what's in there, and I'd rather you made that decision holding real information than a guess. It also means the first check is always the same size, which is a much easier thing to get through anybody's process than a five-figure commitment made on trust.

Payment is by bank transfer, before work starts. No invoicing terms, no chasing, no thirty-day gap between a decision and a start date. For the same reason the price ladder is published: I'd rather spend the time on the work than on the negotiation.

Larger engagements can be split. Above tier 3 it's normal to pay in stages against delivered waves rather than in one go — say so and we'll structure it that way.

In scope: your SuiteScript estate. Cataloged, scored, and then converted — as many or as few scripts as you choose.

Not in scope yet: your integrations. Token-Based Authentication and SOAP web services are being retired on Oracle's published dates, and that's real and worth your attention. Remediating them is on my list to build. It isn't built today, which means it isn't part of this engagement and I won't let it drift into the scope later — but if that's what you actually need, tell me. What people ask for is how I decide what to build next. The timeline, meanwhile, is written up here and it's free.

At the small end, the conversion isn't really what you're buying. Ten scripts, a competent developer converts in a week. What's hard to produce on your own is everything around it: a regression suite derived from your original code, a deployable SuiteCloud project, and an approval trail showing who accepted what. For an account whose customizations have never been in version control — which is most accounts — that's the actual deliverable, and the conversion comes along with it.

A score is only useful if it survives being questioned by somebody senior. So neither of these is mine.

Complexity uses Oracle's published matrix — seven factors, banded Low, Medium, High or Critical. Not my arithmetic, not a proprietary index I could tune to suit a quote. When that number reaches a steering committee and somebody asks where it came from, the answer is Oracle's own documentation.

Risk is scored separately, and it is not the same thing. A trivial script wired into order approval is more dangerous to touch than a gnarly one nobody depends on. Vendor-owned code and APIs with no 2.1 equivalent raise the floor, because those are blockers rather than difficulties. Anything unrated scores middling rather than zero — treating unknowns as harmless is exactly how they get skipped.

The two together let you sequence by exposure instead of by age, which is the difference between a plan and a list.

This is why the output isn't just a count, and it's usually the part that makes a project smaller than feared.

Some of it isn't yours to move. Vendor-owned scripts that arrived with a SuiteApp can't be converted by you or by me — they're the vendor's to update. They get named and routed to whoever owns them, scored as blockers rather than as work, so they never end up quietly inside a quote.

Some of it isn't doing anything. Scripts sitting undeployed. Scripts deployed to a role nobody holds any more. Scripts written for a process the business stopped doing in 2019 that nobody has dared delete. Every one of those is a script you don't have to migrate.

And some of it can't be converted yet. Where a script uses a 1.0 API with no 2.1 equivalent, that's named, with the workaround if one exists. A migration plan that stays silent about those is a plan that falls over in month two.

What you end up with isn't "you have 240 scripts." It's: here are the ones that are yours, here are the ones that are live, here are the ones that are blocked and why, and here's the order I'd move them in.

One read-only connection. That's it.

Nothing is written back to your NetSuite account — not while cataloging, and not while converting. No records created, no scripts deployed, no settings changed. The connection reads; everything I produce lands outside your system, where you look at it before deciding anything.

You also get a login. Read access to the catalog and the scoring as it's produced, so this is something you watch rather than something that arrives as a PDF three weeks later. It's also where your named approver accepts each conversion — nothing reaches your repository without a person in your organization putting their name on it.

That last part matters more than it sounds. AI proposes; a person approves. If I both produced the conversion and accepted it, your audit trail would record the vendor approving the vendor's own work, which is the finding an IT controls review exists to catch. With your approver on the acceptance, the same trail becomes evidence instead.

Does anything change in our account? No. The connection is read-only and nothing is written back at any stage.

What if the catalog says we've barely got a problem? Then you've spent $2,000 to stop worrying about it, and you have a document that says so next time somebody asks. That's a good outcome, and I'd rather find it than talk you into a migration you don't need.

Can we just do this ourselves? Yes, and I'll tell you how on the deadlines pages — none of it is secret. What you're buying is somebody who has done it before, tooling that has already made the mistakes, and a document your auditors will accept. If you'd rather run it in-house, those pages are free and they'll still be there.

Where does the code end up? Wherever you want it. Usually a private GitHub repository you nominate, reached through a GitHub App you install and can revoke at any moment — so your code never leaves your control at all. If you'd rather not connect anything, you get the SDF project as a downloadable zip. And if your customizations have never been in version control, I'll stand a repository up for the engagement and transfer it to your account at the end.

How fast does this go? As fast as you want. I'd rather go slowly. An approval step only means something if the person approving has time to read what they're approving — and code arriving faster than anyone can review it doesn't make approval quick, it makes it ceremonial.

We're not sure we'd migrate at all. Reasonable — SuiteScript 1.0 has no announced end-of-support date, whatever you may have read elsewhere. Start at tier 1 and find out whether you need to care. That's a much smaller question than committing to a project.