Legacy application replacement
The official YesSoftware site says the CodeCharge Studio project is closed, although it still links to the latest installer. An existing application does not stop running because its development project closed, but its owner still needs a maintainable path for future changes.
The safe approach is to preserve compatible data and requirements, select the new runtime deliberately, and rebuild one representative workflow before planning the full cutover.
Migration summary: there is no verified one-click import from a CodeCharge project into PHPRunner or ASPRunner.NET. Treat the database, views, procedures, and documented rules as potential reusable assets. Treat pages, events, permissions, templates, integrations, and custom code as items to inspect and recreate or adapt.
This guide was prepared by Xlinesoft and fact-checked on 17 October 2026. The historical CodeCharge Studio 5 manual documents projects that could target PHP, ASP.NET C# or VB, classic ASP, Java/JSP, ColdFusion, and Perl. The original runtime therefore matters when choosing a replacement; not every CodeCharge application should follow the same path.
| Asset | Assessment | Likely treatment |
|---|---|---|
| Database schema, data, views, procedures, triggers | Confirm engine/version, ownership, keys, write paths, and compatibility | Potentially reusable after backup and testing |
| CodeCharge project and generated source | Record target language, project version, build environment, and custom changes | Reference for requirements; no direct import assumed |
| Pages, forms, reports, exports | Identify who uses each and which are still needed | Recreate in the new project |
| Events and custom code | Separate business rules from framework-specific implementation | Rewrite or adapt to current APIs |
| Authentication and permissions | Document users, roles, record ownership, SSO, and denied actions | Redesign and retest explicitly |
| Integrations, files, email, jobs | Record endpoints, schedules, credentials location, and failure handling | Rebuild with supported components |
PHPRunner is the more direct Xlinesoft path when the new application should run on a compatible PHP web server. ASPRunner.NET is the corresponding path when the required environment and maintainers are centered on ASP.NET and C#. Both connect to common relational databases and create forms, search, reports, dashboards, authentication, permissions, and extensible application events.
The historical CodeCharge language does not force the new choice, but changing runtime adds work. Confirm hosting policy, staff skills, existing reusable services, database drivers, and production support before deciding.
Use a backup or staging database; record baseline counts, totals, and critical calculations.
Include related records, validation, two roles, one report, and one external integration.
Check successful work, denied operations, reports, exports, calculations, and integration side effects.
Publish to the intended environment, then make a schema or rule change through the supported workflow.
Classify remaining modules as reusable, adaptable, rebuild, or unknown only after the pilot reveals the real work.
Define which application may write each record during transition. Running old and new applications against the same production tables can cause conflicts unless write ownership is explicit. Establish a cutover window, reconciliation checks, rollback trigger, and the authoritative system for changes made during the transition.
Handover documentation should include the new project, custom code, build instructions, server and database requirements, deployment process, licenses, and named maintenance owner. Count developer editions, support and upgrades, hosting, database costs, and training; do not promise a migration duration before the inventory and pilot.
The goal is not to reproduce every old screen. It is to preserve correct data and business behavior while removing obsolete pages, making permissions testable, and giving a future maintainer a supported way to change and deploy the application. Evaluate PHPRunner and ASPRunner.NET according to the selected runtime and the team responsible for version two, not only the speed of the first rebuild.