SDF vs SuiteBundler: Which to Use for NetSuite Customizations

Quick summary: SuiteBundler and SuiteCloud Development Framework (SDF) both package and move NetSuite customizations between accounts, but they represent two eras. SuiteBundler is a UI-driven bundling tool that is now in maintenance mode — supported, but receiving no new features. SDF is a file-based framework where customizations are XML definitions and SuiteScript files you build, version-control, validate, and deploy from an IDE or the SuiteCloud CLI. For new work, Oracle steers teams to SDF (plus Copy to Account and SuiteApp Control Center); SuiteBundler remains viable for simple, non-developer distributions and mature bundles already in flight. This guide compares them honestly and shows how to choose.

We’ve shipped customizations both ways across ecommerce, wholesale, and B2B finance accounts in the US, UK, CA, Australia, and New Zealand. The comparison below is the one we actually use with clients — not a feature checklist, but the handful of decisions that determine which tool saves you pain.

What each tool actually is

They solve the same problem — moving customizations between accounts — from opposite directions:

• SuiteBundler — you build customizations in the NetSuite UI, group them into a bundle, and distribute it publicly, to a list of accounts, or shared. Installs and managed-bundle updates happen inside NetSuite. It’s approachable for non-developers but no longer being enhanced.
• SDF — you represent customizations as XML SDF custom objects plus SuiteScript files in a project folder, develop them locally in VS Code or WebStorm (or via the CLI), and deploy with validation. It decouples development from any single account, so you get versioning and CI/CD. (See the SuiteCloud Development Framework docs.)

Two deployment models

The real difference is the mental model. SuiteBundler is account-centric: the source of truth is the customization living in a NetSuite account, and the bundle is a snapshot. SDF is file-centric: the source of truth is the project on disk, and the account is a deploy target. That single shift is why SDF unlocks Git diffs, branching, code review, and pipelines — and why it feels alien to admins used to clicking through the UI.

SDF projects come in two types. An Account Customization Project (ACP) is for accounts you own (production, sandbox, dev). A SuiteApp project is for distributing to accounts you don’t control — the modern equivalent of a managed bundle, published through SuiteApp Control Center. (Reference: SuiteCloud Project Types.)

my-acp-project/
├── manifest.xml          # project type + dependencies
├── deploy.xml            # what gets deployed
└── src/
    ├── Objects/          # XML: customrecord_*, customform_*, workflow_*
    ├── FileCabinet/      # SuiteScript files, templates
    └── Translations/

# validate, then deploy — from your terminal
suitecloud project:validate --server
suitecloud project:deploy

Head-to-head comparison

Two caveats keep this honest. SDF still doesn’t support every customization type — the list grows each release, but check the supported-objects reference before assuming coverage. And SDF’s validation errors can be verbose and cryptic, which raises the learning curve for teams new to it.

How to choose

"Don't choose by taste. Choose by who ships it, whether it's form-heavy, and whether you need Git. Those three answers decide it more often than any feature list."

Our rule of thumb:

1. New, developer-owned work → SDF. The versioning and CI/CD payoff lands within the first year.
2. Distributing to external clients → SDF SuiteApp project + SuiteApp Control Center; managed SuiteApps update automatically.
3. Copying a single object between your own accounts → Copy to Account — lighter than a full project for one-offs.
4. Simple distribution owned by admins, no Git need → SuiteBundler is still the path of least resistance.
5. A mature bundle already near release → finish it on SuiteBundler; don’t switch horses mid-stream.

Moving bundles to SDF

You can convert a bundle you administer into an SDF account customization project; the converted customizations are saved as a zip in the File Cabinet for further development. What you can’t do is convert a bundle directly into a SuiteApp project — you convert to an ACP first, then copy objects into a SuiteApp project. (Reference: Moving from SuiteBundler to SDF.)

Pitfalls & gotchas

• ACPs can’t be uninstalled once deployed — never use an ACP for something you may need to remove from a client account.
• Form layouts: Bundler resets them on each install/update; if forms matter, that alone justifies SDF.
• Unsupported objects: some types still can’t be deployed by SDF — confirm before you commit an approach.
• Project size: the deployed SDF project zip is capped (50 MB) — push large files to the File Cabinet rather than into the project.
• Cryptic errors: budget time to learn SDF validation messages; they’re powerful but not always self-explanatory.

Key takeaways

• Same job, two eras: Bundler is UI-driven and frozen; SDF is file-based and actively developed.
• SDF’s superpower is the file-centric model — Git, diffs, review, and CI/CD.
• Pick by audience, form-sensitivity, and version-control needs, not by habit.
• ACP for your accounts, SuiteApp for external distribution, Copy to Account for one-off objects.
• Mind the duplication trap and the no-uninstall ACP rule when migrating bundles.

If you’re sitting on a pile of legacy bundles and weighing the move, talk to one of our engineers — we’ll assess your estate and recommend a path, not a rewrite for its own sake. You can also browse our other NetSuite engineering articles.

Frequently asked questions

Is SuiteBundler deprecated or going away?

SuiteBundler is not removed, but it is in maintenance mode — it still works and is supported, yet it no longer receives new features. Oracle now points customers to SuiteCloud Development Framework (SDF), Copy to Account, and SuiteApp Control Center for packaging and distributing customizations. Your existing bundles keep working, but new platform capabilities ship to SDF first, so new development should target SDF.

Can I convert an existing SuiteBundler bundle to SDF?

Partly. You can convert a bundle you administer into an SDF account customization project (ACP); the converted customizations are saved as a zip in the File Cabinet and can be developed further in an IDE or the CLI. You cannot convert a bundle directly into a SuiteApp project — you convert to an ACP first, then copy the objects into a SuiteApp project. Note that ACPs cannot be uninstalled once deployed, so plan the target project type carefully.

Do I need to be a developer to use SDF?

Effectively yes. SDF is developer-oriented: customizations are XML files in a project folder, edited in an IDE like VS Code or WebStorm or driven through the SuiteCloud CLI, validated, and deployed from the command line. That’s a great fit for engineers who want Git history and CI/CD, but a higher bar for admins and functional users — who often find SuiteBundler’s point-and-click packaging easier for simple distributions.

Should I use SDF or SuiteBundler to distribute to clients?

For new distribution to external accounts, build an SDF SuiteApp project and publish through SuiteApp Control Center — managed SuiteApps update automatically and get Oracle’s newer capabilities. SuiteBundler can still distribute publicly, by account list, or shared, and remains simpler for non-developers, but it won’t gain new features. If you’re mid-flight on a mature bundle with a large install base, finishing on SuiteBundler is reasonable; new builds should start on SDF.

Does SDF support every customization type?

No. SDF supports more customization types than SuiteBundler and the list grows each release, but it still can’t deploy everything — always check the official supported-objects reference before assuming a record type is covered. SDF also preserves form layout far better than SuiteBundler, which resets form customizations on install and on subsequent updates, so form-heavy deployments are a strong argument for SDF.