Modernizing a legacy .NET application
An Iron Speed Designer application may still run, but its owner may need a current development workflow for new requirements, security updates, and future maintainers. The official version history lists 12.2.0 from 20 August 2015 as its newest published release; that historical page alone does not prove current sales, activation, or support policy.
For a team that intends to remain on a .NET-centered path, ASPRunner.NET is the first Xlinesoft option to evaluate.
Migration summary: do not expect ASPRunner.NET to open an Iron Speed project. Preserve a verified database and documented requirements where appropriate, then rebuild the pages, permissions, events, reports, and integrations in a current project. Existing C# or VB.NET custom code is reference material until its APIs and dependencies are proven compatible.
This Xlinesoft guide was fact-checked on 17 October 2026. It uses the official Iron Speed release history only for documented historical facts and does not assert an unverified company closure or exact current support status.
Record the Iron Speed version, generated source, database schema and objects, reports, authentication, role and row-access rules, custom C# or VB.NET, third-party assemblies, scheduled work, integrations, file storage, build tools, and hosting configuration. Also identify unused pages and rules that users have replaced with manual workarounds.
Classify each item as potentially reusable, requiring adaptation, requiring rebuild, or unknown. Database assets may survive the change even when the UI and framework code do not.
ASPRunner.NET builds browser-based applications around supported relational databases and provides forms, related records, search, reports, dashboards, authentication, groups, permissions, Page Designer, and C# events. Its current 11.3 product uses a Windows development environment and deploys to a compatible .NET web-server environment.
This keeps the replacement in the .NET skill area, but it does not make old framework code drop-in compatible. Reimplement each rule with current ASPRunner.NET events and APIs, and test any reused library against the selected .NET and server environment.
| Keep after review | Rebuild or adapt | Prove before cutover |
|---|---|---|
| Database records, keys, views, procedures, and documented rules that remain valid | Pages, navigation, project configuration, events, templates, permissions, and integrations | Record totals, calculations, denied actions, reports, exports, jobs, and external side effects |
| Requirements and user vocabulary | Custom C#/VB.NET tied to Iron Speed APIs or old dependencies | Build reproducibility, runtime dependencies, deployment, rollback, and future change process |
Use a staging database and establish baseline counts, totals, and critical calculations.
Include master-detail data, validation, employee and manager access, a report, and one customization.
Try denied direct URLs, exports, invalid inputs, integration errors, and missing dependencies, not only the happy path.
Publish to the intended environment, change one field or rule, rebuild, and confirm that custom work remains correct.
Assign write ownership during transition. If the old and new applications both update the same records, define a narrow parallel period and explicit reconciliation rules. Prepare a rollback trigger, deployment package, database backup, and verification checklist before redirecting users.
Document who maintains the new project, which ASPRunner.NET edition they need, and how support, upgrades, server runtime, database, and third-party components are maintained.
PHPRunner can be considered when the organization intentionally wants a PHP-server deployment and has the skills and infrastructure to support it. That can be a valid architectural change, but it should not be presented as the default replacement for a .NET-centered application. ASPRunner.NET avoids that additional runtime decision and is therefore the clearer first pilot for most .NET maintainers.