How do I keep custom code safe during an AuctionWorx upgrade?

Catalog all modifications before upgrading. Test on staging first, diff your custom files against the new release, then reapply changes through supported extension points instead of editing core files.

What breaks most often when upgrading AuctionWorx?

Custom Razor views and templates break frequently because new releases update core markup. Database schema changes, payment gateway hooks, and mobile API endpoints are also common failure points.

Should we test upgrades on a staging server?

Absolutely. Always. A staging environment lets you identify conflicts, practice rollback, and run a complete regression test without risking live auctions or bidder accounts.

AuctionWorx Upgrade Checklist - Protect Your Customizations

An AuctionWorx upgrade should bring performance improvements and new capabilities without creating operational panic. If your site has run for more than a year, it probably deviates from stock configuration. Custom commission tiers, branded themes, tailored payment processors, or custom mobile APIs power your differentiation. When the core platform installer runs, it can easily overwrite modifications if they landed in the wrong directories.

This checklist follows the approach in Systenics’ upgrade playbook and helps you upgrade cleanly and protect your customizations.

Pre-Upgrade Customization Audit

Before you touch an upgrade package, inventory every custom element. Knowing exactly where your codebase differs from stock AuctionWorx prevents surprise breakage during deployment.

Catalog these immediately:

All custom controllers, services, and helper classes outside standard modules
Theme overrides, Razor views, and custom CSS or JavaScript bundles
Every database schema modification (custom tables, added columns, modified stored procedures)
External integrations like payment processors, SMS gateways, shipping APIs, mobile app feeds
Current AuctionWorx version, .NET runtime, IIS settings, server dependencies
Git repository ownership and whether all production patches are committed to version control

If this inventory is difficult to pull together quickly, that signals a red flag: previous modifications were made directly inside core files instead of using supported hooks or override folders. When code is edited in vendor files, every upgrade requires tedious manual diffing. That technical debt costs real time to resolve during upgrades.

Mirror and Rehearse on Staging

Never upgrade production directly. A dedicated staging environment lets you test safely, uncover conflicts early, and rehearse your exact cutover procedure.

Staging setup checklist:

Clone your production database and web files into an isolated staging server
Scrub or anonymize user credentials, bidder records, and payment tokens (compliance requirement)
Match production IIS pool settings, SSL bindings, caching rules, and network configuration
Apply the AuctionWorx upgrade package to staging
Run a Git diff to identify overwritten or conflicting files
Refactor fragile customizations into supported extension points provided by the newer release
Clock the exact time each step takes (database migration, file deployment, smoke testing)

Backup and Restore Fire Drill

A backup is only as good as your ability to restore it under pressure. Before touching live production, verify your rollback procedure works.

Backup checklist:

Create a full SQL database backup (verify the backup file is readable)
Compress the entire web application directory into an archive
Test restore on a secondary server to confirm the database attaches and the site boots cleanly
Document the exact restore time and success criteria
Ensure backups live in secure off-site storage, not on the production host

Regression Testing - The Real Work

Once staging runs the upgraded version, work through the full end-to-end checklist below. Quick spot checks are not enough when real bids and payments are at stake.

Test these workflows thoroughly:

Bidding logic - Standard bids, proxy increments, reserve thresholds, bid history timestamps, sniper protection
Invoicing and fees - Buyer premiums, custom fee structures, sales tax calculations, consignor settlement math
Payment processing - Full end-to-end checkout through each active payment gateway in sandbox mode
Notification delivery - Outbid alerts, invoice emails, user registration confirmations, custom transactional alerts
Listing management - Publish listings with custom attributes, file attachments, and media galleries
Operational reports - Financial statements, seller settlements, buyer account history
Mobile API endpoints - JSON payloads and authentication tokens match what mobile apps expect
Custom extensions - Any background sync jobs, ERP integrations, or third-party plugins

Rollback Triggers and Decision Criteria

Decide on go/no-go criteria before the maintenance window starts. Clear criteria eliminate improvisation under pressure.

Define your rollback thresholds:

Core workflows that are non-negotiable (if checkout or proxy bidding fails, rollback is mandatory)
A single technical lead with final authority to call a rollback
A hard cutover time limit (if smoke tests are not fully green by deadline, rollback and reschedule)
Keep the restore playbook and timing accessible to the entire deployment team

Live Cutover Execution

Once staging tests pass and rollbacks are verified, deployment day becomes ordered execution.

Cutover day checklist:

Schedule cutover during historically low-traffic hours, no active auctions closing during maintenance
Notify your community in advance (email and site announcements with clear dates and duration)
Display a branded maintenance landing page while database migrations run
Execute rapid post-deploy smoke testing (authentication, listings, bidding, payment processing)
Monitor server health metrics, exception logs, and support queue throughout initial live hours
Have senior technical staff on standby for the first hours after cutover

Common Upgrade Mistakes to Avoid

Don’t modify core files directly. Use supported extension points, partial classes, or override folders. Editing vendor files creates technical debt that multiplies with each release.

Don’t skip staging. Testing on production is how auction sites go down. Staging is non-negotiable.

Don’t assume database schema hasn’t changed. Undocumented schema changes break custom code silently. Diff your database carefully.

Don’t forget to test payment gateways in sandbox. Every active gateway and any custom gateway hook must be validated before going live.

Don’t update your mobile API contract without testing mobile apps. A breaking change in the API breaks your iOS or Android app instantly.

After Your Upgrade Succeeds

Once you are live and stable, document what went well and what was unexpected. This foundation informs your next upgrade cycle. Clean up technical debt while the codebase is fresh. Update your Git repository with the new baseline so future upgrades are easier.

Upgrading AuctionWorx does not have to be a white-knuckle process. With proper planning, staging rehearsals, and a solid regression checklist, you move forward confidently. If you are preparing for a major version jump or need help untangling legacy modifications, we can partner with your team to deliver a smooth, reliable upgrade.

Reach out to our team to discuss your upgrade timeline and strategy.

Related Resources:

For more places to read up before you start, see the AuctionWorx documentation guide.