Skip to content

PlanUpgradeToBeConsidered.md

Latest commit

 

History

History
241 lines (168 loc) · 12.7 KB

PlanUpgradeToBeConsidered.md

File metadata and controls

241 lines (168 loc) · 12.7 KB
Raw

TaskMonitor Upgrade Recommendations

Executive recommendation

Recommendation date: 23 July 2026

Do not begin the Windows Service, bulk-import, managed-archive, observability-platform, or cross-platform rewrites before the migrated workflows have been proven compatible with the production schema and real legacy packages.

The recommended order is:

  1. Prove database and legacy package compatibility.
  2. Close credential, recovery, and transfer-posting risks.
  3. Complete a controlled side-by-side pilot and choose the deployment model.
  4. Measure production-like performance.
  5. Implement only the upgrades justified by those measurements and deployment requirements.

The current .NET 8/WPF architecture is sufficiently separated into Domain, Application, Infrastructure, and Desktop projects to support these upgrades incrementally. A broad rewrite before compatibility validation would increase cutover risk without proving business value.

Decision summary

Proposal Recommendation Timing Reason
Production-schema and SQL validation Approve Immediate; cutover blocker Generated operations have not been validated for every production table.
Legacy .Fil and archive compatibility testing Approve Immediate; cutover blocker Real ADO XML and RAR/ZIP compatibility remain unproven.
Transfer-posting integration and recovery tests Approve Immediate; cutover blocker Transfer processing changes inventory and audit tables and must be proven exactly once.
Credential protection and configuration cleanup Implemented; verify operational setup Before pilot Archive encryption was removed; database passwords remain runtime-only.
Set-based import with TVP/SqlBulkCopy Conditionally approve After benchmark It is valuable only if measured import time, locking, or timeout behavior is unacceptable.
Managed archive engine Conditionally approve After compatibility test Packages are unencrypted ZIP content with legacy .rar names, making a future managed ZIP implementation practical.
Windows Service Conditionally approve Before go-live only if unattended execution is required WPF/tray hosting is acceptable for an attended workstation but not for a logged-out server.
Structured logging and operational alerts Approve in stages Basic logging before pilot; centralized telemetry after stabilization Local diagnostics are needed immediately; a full observability stack is not.
Avalonia, REST, gRPC, or cross-platform rewrite Defer Reassess after stable production operation No current requirement justifies the cost or compatibility risk.

Phase 0: Cutover evidence and safety

Decision: start now. These items are release gates, not optional upgrades.

1. Validate the production database contract

Validate generated selects, parameters, data types, null behavior, key handling, and transaction boundaries against a restored non-production copy for:

  • tblProducts
  • tblBarcode
  • tblDepartments
  • tblVendors
  • tblUsers
  • tblServerLog
  • tblAuditTrail
  • tblTransAudit
  • tblTransAuditDetails

For each workflow, compare the database state produced by VB6 and .NET from the same starting backup and input package. Resolve the product-quantity behavior explicitly because the VB6 routine contains an early exit.

Exit criteria

  • Import, export, and transfer SQL match the real schema.
  • VB6 and .NET results are reconciled or every intentional difference is approved.
  • A failed multi-table import or transfer rolls back completely.
  • Reprocessing a completed transfer cannot alter inventory twice.

2. Prove legacy file and archive compatibility

Obtain representative production/test packages and add golden-file tests for every legacy file:

  • ProdQtyDb.Fil
  • SynchDb.Fil
  • BarcodeDb.Fil
  • DeptDb.Fil
  • tblVendors.FIL
  • tblUsers.FIL
  • ItemList.Fil

Test both directions:

  • The .NET reader accepts real ADO adPersistXML files.
  • The legacy consumer accepts files produced by the .NET writer.
  • Current WinRAR commands create and extract every supported product and transfer package name.
  • Unencrypted product and transfer packages are accepted by every participating program.

Determine whether .rar files are true RAR archives or ZIP archives with a .rar extension before selecting a replacement library.

Exit criteria

  • Golden files are checked into an approved, sanitized test-data location.
  • Package creation and extraction pass on a clean deployment-like workstation.
  • The unencrypted ZIP format and legacy .rar naming contract are documented.

3. Add production-like integration and recovery tests

Keep the fast executable self-tests, but add a separate integration suite using a restored or disposable SQL Server database. Cover:

  • Vendor, department, user, product, quantity, and barcode imports.
  • Transfer sign handling and all audit records.
  • Duplicate package receipts and quarantine behavior.
  • Database success followed by archive-move failure.
  • Malformed, incomplete, duplicate, and oversized packages.
  • Cancellation and restart during each workflow.

Do not use a live production database for automated tests.

4. Enforce credential handling

Archive encryption and all archive-password settings have been removed. TaskMonitor creates and extracts unencrypted ZIP-compatible packages while retaining the legacy .rar filename. Prefer Windows Integrated Security for SQL Server and use TASKMONITOR_DB_PASSWORD only when SQL authentication is unavoidable.

Before pilot:

  • Configure secrets for the actual process or dedicated service identity, not an unrelated interactive account.
  • Restrict configuration and application-directory ACLs to authorized identities.
  • Confirm diagnostics and archive operations under the deployment identity.
  • Rotate any database or retired archive credential that previously appeared in a local configuration or build output.
  • Consider DPAPI or an enterprise secret provider only if environment-based provisioning does not satisfy operational policy.

Phase 1: Pilot and deployment decision

Decision: complete after Phase 0 and before live cutover.

5. Run a controlled side-by-side pilot

Use copied data and identical package inputs to run VB6 and .NET in parallel without allowing both applications to process the same live queue.

Record:

  • Package and row counts.
  • Database changes by table.
  • Import/export duration.
  • SQL command duration and timeout/locking evidence.
  • Archive creation/extraction results.
  • Failed/quarantined package recovery.
  • Scheduler behavior across restart, logoff, and reboot.

Start in Recording mode, progress to Database mode against the test database, and then conduct a limited live pilot with a documented rollback procedure. Retain the VB6 executable until the acceptance criteria are met.

6. Choose the hosting model

Use the existing WPF/tray application if:

  • It runs on an attended Windows workstation.
  • A user session is expected to remain active.
  • Manual controls and tray visibility are operational requirements.

Create TaskMonitor.Service if:

  • Processing must continue while all users are logged out.
  • Automatic recovery after reboot is required.
  • The target is a server or locked-down back-office host.

If a service is required, move scheduling and processing into a .NET Worker/Windows Service while retaining the existing Application and Infrastructure layers. Defer named pipes or gRPC until there is a proven need for a separate live console; service logs/status files or a small local status endpoint may be sufficient initially. Run under a dedicated least-privilege service account, not LocalSystem, unless an explicit security review approves it.

Phase 2: Evidence-driven optimization

Decision: measure first.

7. Benchmark before adopting TVPs or SqlBulkCopy

The current plan's “20x-50x” improvement and “under one second” target are not established by repository evidence. Create a repeatable benchmark with representative row widths and packages of approximately 1,000, 10,000, and expected maximum size.

Capture:

  • End-to-end package duration.
  • Database execution time by table.
  • Rows per second.
  • Transaction-log growth.
  • Blocking, deadlocks, and lock escalation.
  • CPU and memory use.

Adopt staging tables plus SqlBulkCopy, TVPs, or set-based MERGE alternatives only when a documented service-level objective is missed. Prefer explicit UPDATE/INSERT operations over SQL Server MERGE unless its concurrency behavior is carefully tested.

Suggested trigger

  • A normal package exceeds the agreed processing window.
  • Commands approach their timeout.
  • Row-by-row execution causes measurable blocking or excessive log growth.

Preserve the existing repository interfaces so the optimized implementation can be introduced table by table.

8. Decide the archive strategy from the required format

Confirmed requirement Recommended approach
ZIP content; extension can change System.IO.Compression
ZIP content; legacy .rar filename must remain Managed ZIP with explicit compatibility tests and documentation
Current unencrypted ZIP content with legacy .rar name Keep the tested WinRAR adapter initially; then consider System.IO.Compression behind IArchiveService

Do not remove WinRAR until real downstream compatibility with a managed ZIP implementation is demonstrated. Wrap any replacement behind IArchiveService, keep the legacy package names, and test on the clean target image.

Phase 3: Operational hardening

9. Introduce observability in two increments

Before pilot

  • Write structured local logs with package fingerprint, file name, workflow, stage, duration, row counts, and final disposition.
  • Add log retention and prevent secrets from entering messages.
  • Produce an operator runbook for Failed, Quarantine, and recovery scenarios.

After stabilization or multi-site rollout

  • Add centralized log shipping and OpenTelemetry metrics if operations has a supported destination.
  • Alert on repeated failures, backlog age, scheduler inactivity, and quarantine growth.
  • Select Teams, email, webhook, or another channel based on the organization's supported platform; do not hard-code a vendor before that decision.

An arbitrary ten-second notification target is unnecessary unless operations defines it as an SLA.

Phase 4: Deferred platform evolution

Do not start an Avalonia, web, REST, gRPC, Linux, or container migration during the compatibility and cutover program. Reassess only if there is an approved requirement for:

  • Linux/container deployment.
  • Central remote administration.
  • Near-real-time exchange instead of batch packages.
  • External API consumers.

At that point, keep the proven Application/Domain logic and introduce a new host or transport rather than rewriting the synchronization rules.

Recommended delivery sequence

Order Deliverable Gate
1 Schema validation and VB6/.NET database comparison All table mappings approved
2 Golden legacy files and archive compatibility suite Bidirectional compatibility proven
3 Transfer, duplicate, rollback, and recovery integration tests Exactly-once and rollback scenarios pass
4 Credential policy implementation and documentation cleanup No unapproved plaintext production secrets
5 Controlled pilot and operational runbook Business and operations sign-off
6 Hosting decision and, if required, Windows Service Reboot/logoff acceptance test passes
7 Performance benchmark Baseline and target agreed
8 Targeted batching/archive/telemetry upgrades Implement only triggered items
9 Controlled live cutover Rollback plan rehearsed

Acceptance checklist

  • All production table mappings are validated against a restored database.
  • Real legacy .Fil files pass reader and writer compatibility tests.
  • Product and transfer archives pass creation/extraction tests on a clean host.
  • Transfer posting, duplicate detection, rollback, and archive-failure recovery pass integration tests.
  • Archive encryption and archive-password configuration are removed.
  • The Create Transfer program is updated to create unencrypted packages.
  • The runtime database secret is provisioned and verified under the deployment identity if SQL authentication is used.
  • VB6 and .NET side-by-side results are reconciled.
  • Deployment model is approved and survives the required logoff/reboot scenarios.
  • Performance baseline meets an agreed service-level objective, or a targeted optimization is completed.
  • Logs, retention, alerts, operator recovery, and rollback procedures are documented.
  • A controlled pilot is approved before full cutover.