Legacy Modernization, Governance, and Future Directions

Introduction and Context

Visual Basic has occupied a distinctive position in software engineering. Classic Visual Basic enabled rapid development of Windows applications, while Visual Basic .NET introduced managed execution, object-oriented programming, structured exception handling, generics, asynchronous programming, and integration with the .NET ecosystem. Many institutions still operate software written in Visual Basic 6, VBA, VBScript, or early versions of Visual Basic .NET. These systems may support payroll, manufacturing, laboratory administration, banking, education, or public services.

The continued use of such systems is not necessarily evidence of poor engineering. A legacy application often embodies valuable business rules, accumulated operational knowledge, stable integrations, and years of validated data. The difficulty is that its technical foundations may no longer align with current requirements for security, interoperability, maintainability, cloud deployment, observability, regulatory compliance, and organizational agility.

Legacy modernization is therefore not simply the replacement of old source code. It is a socio-technical transformation involving architecture, data, people, processes, risk, governance, and business continuity. For Visual Basic professionals, modernization requires both programming knowledge and the ability to evaluate the strategic role of an existing system.

Learning Objectives

After completing this chapter, a learner should be able to:

1. Explain the meaning and characteristics of legacy Visual Basic systems.
2. Distinguish modernization, migration, replacement, and retirement.
3. Select an appropriate modernization strategy using technical and business evidence.
4. Analyze code, dependencies, data, interfaces, and operational risks.
5. Design governance controls for Visual Basic development and modernization.
6. Apply testing, security, configuration, and release-management practices.
7. Evaluate the role of APIs, cloud services, DevOps, and artificial intelligence in modernization.
8. Critically assess risks, costs, ethics, and future directions.

1. Understanding Legacy in the Visual Basic Context

A legacy system is an information system that remains important to an organization but is difficult to change, operate, secure, or integrate. Age alone does not define legacy status. A ten-year-old application with automated testing, documented interfaces, and active vendor support may be easier to maintain than a three-year-old application with undocumented dependencies and fragile deployment procedures.

Visual Basic legacy environments commonly include:

• Visual Basic 6 desktop applications using forms, ActiveX controls, COM components, and ADO.
• VBA solutions embedded in Microsoft Excel, Access, Word, or other Office applications.
• VBScript used for administration, web pages, login scripts, or batch processing.
• Early Visual Basic .NET applications using Web Forms, Windows Forms, typed DataSets, or tightly coupled business logic.
• Hybrid systems in which Visual Basic calls stored procedures, unmanaged DLLs, COM servers, or external executables.

The principal characteristics of such systems are often more important than the language version:

A legacy system can nevertheless contain significant assets: reliable algorithms, accurate historical data, established workflows, and interfaces that users understand. Modernization should preserve these assets while reducing avoidable constraints.

2. Modernization as a Socio-Technical Decision

Modernization is the deliberate improvement of an existing system’s technology, architecture, delivery process, or operating model while preserving or enhancing required business capability. It may involve source-code transformation, platform migration, architectural restructuring, data redesign, interface development, or gradual replacement.

Four concepts should be distinguished:

Maintenance changes an existing system to correct faults, adapt to a changed environment, or improve performance. Modernization improves the system’s technical and operational fitness, often without changing its fundamental business purpose. Migration moves software, data, or execution to another platform or environment. Replacement substitutes a new product or application for the old one. Retirement removes a system after its functions and data have been dealt with.

A useful decision principle is to compare the value of intervention with its total risk and cost. A simplistic cost equation is not sufficient for an investment decision, but the following decomposition is useful:

Here, TCO is total cost of ownership over a selected period; C_a is acquisition or development cost; C_o is operating and support cost; C_r is risk-related expected cost; and C_c is change and compliance cost. These terms must be estimated over the same time horizon and monetary basis. The risk-related term may include expected losses from outages, security events, failed releases, or regulatory penalties. It is an estimate, not a guaranteed prediction.

An organization should not modernize merely because a technology is old. It should modernize when the current system creates material business, security, operational, or strategic limitations, and when a credible target state can reduce those limitations.

3. A Modernization Taxonomy

3.1 Retain and stabilize

The organization keeps the current application but documents it, applies security controls, introduces monitoring, removes unsupported components, and improves backup and recovery. This is appropriate when the system is stable, differentiation is low, and replacement risk is high.

3.2 Rehost

The application is moved with minimal code change to a supported server, virtual machine, or cloud environment. Rehosting can improve infrastructure support, but it does not automatically solve poor design, weak security, or obsolete application dependencies.

3.3 Replatform

The system is moved to a substantially improved runtime or database platform with limited functional change. Examples include moving a database to a supported managed service or replacing an obsolete web server while preserving application behavior.

3.4 Refactor

The internal structure is improved without intentionally changing externally visible behavior. A Visual Basic application may be divided into presentation, application-service, and data-access layers; duplicated code may be consolidated; and database access may be isolated behind interfaces.

3.5 Rearchitect

The system’s major technical structure changes. For example, a monolithic VB.NET application may expose selected capabilities through secure APIs while retaining the existing core temporarily. Rearchitecture is more disruptive than refactoring and requires stronger architectural governance.

3.6 Rebuild or replace

The organization develops or procures a new system. This is appropriate when the legacy application prevents essential strategic change, cannot meet security obligations, or has become more expensive to operate than a credible alternative. Replacement is not automatically safer: a new system may lose undocumented rules or introduce migration defects.

3.7 Retire

The application is decommissioned after users are migrated, records are retained according to policy, interfaces are removed, and evidence of closure is recorded.

These strategies are not mutually exclusive. A portfolio may retain a stable payroll component, rehost an application server, refactor a business-rule library, and replace a customer-facing interface.

4. Discovery and Assessment

Modernization begins with evidence. Source-code inspection alone is insufficient because behavior may be distributed across database triggers, scheduled tasks, spreadsheets, registry settings, COM components, file shares, and user procedures.

4.1 Application inventory

For each application, record its owner, business purpose, users, criticality, technology version, deployment model, interfaces, data stores, support arrangements, and regulatory relevance. The inventory should identify whether the application is a system of record, a system of engagement, a reporting tool, or a temporary utility.

4.2 Dependency mapping

Dependency analysis should cover both static and dynamic relationships. Static analysis examines project references, imports, COM registrations, configuration files, database calls, and build scripts. Dynamic analysis observes network connections, file access, database activity, scheduled execution, and interactions with external services.

A dependency map should distinguish:

• Technical dependencies, such as runtimes and libraries.
• Data dependencies, such as shared tables and file formats.
• Process dependencies, such as approval procedures and batch schedules.
• Human dependencies, such as specialist knowledge.
• Contractual dependencies, such as vendor support and licensing.

4.3 Code and architecture assessment

Important questions include:

• Is business logic embedded in event handlers or user-interface forms?
• Are database credentials stored in source code or configuration files?
• Are errors silently ignored or logged with insufficient context?
• Are global variables used to communicate state?
• Are COM objects released predictably?
• Are database queries parameterized?
• Can components be tested independently?
• Is 32-bit execution required?
• Are external files, registry keys, or machine-specific paths assumed?

The presence of On Error Resume Next in Visual Basic code deserves particular scrutiny. It can be useful in narrowly controlled compatibility operations, but broad use may conceal failures and produce corrupted or incomplete outcomes.

4.4 Business and operational assessment

Technical quality must be interpreted alongside business impact. A small application may be operationally critical if it controls a manufacturing machine or produces legally significant records. Conversely, a large application may be low risk if it supports an infrequently used internal report.

A practical assessment uses dimensions such as business criticality, change frequency, security exposure, technical health, data sensitivity, vendor support, and modernization feasibility. Scores should be accompanied by evidence and reviewed by both technical and business stakeholders; numerical scoring does not eliminate judgment.

5. Target Architecture for Modernized Visual Basic Systems

A common target is a layered architecture:

1. Presentation layer: Windows Forms, web interface, desktop client, or Office integration.
2. Application layer: use-case coordination, authorization decisions, transactions, and orchestration.
3. Domain layer: business concepts and rules, independent as far as practical from user interface and database technology.
4. Infrastructure layer: database access, messaging, file systems, external APIs, logging, and identity services.

This arrangement is not a universal requirement. It is valuable because it reduces the impact of change and improves testability. A VB.NET application can gradually move logic out of form event handlers into classes and services without an immediate full rewrite.

Modernization frequently benefits from an anti-corruption layer. This is an adapter that translates between legacy representations and modern domain models. For example, a legacy database may use single-character status codes and nullable fields with inconsistent meanings. An adapter can translate these values into explicit modern types while shielding new components from legacy conventions.

An incremental pattern known as the strangler approach introduces new functionality around an existing core and transfers capabilities gradually. Routing, authentication, monitoring, and data ownership must be managed carefully. The pattern is unsuitable when the old and new systems cannot safely coexist or when hidden shared-state behavior makes separation impossible.

APIs should be designed around stable business capabilities rather than simply exposing database tables. They require authentication, authorization, input validation, versioning, rate controls where appropriate, meaningful error responses, auditability, and documented contracts. A legacy VB application can consume or expose APIs, but an API facade does not by itself make an architecture modern or secure.

6. Data Modernization and Integrity

Data is often the most difficult part of modernization. Problems include duplicate records, undocumented codes, inconsistent dates, obsolete identifiers, missing constraints, and dependencies on database-specific behavior.

A data modernization plan should define:

• Data ownership and stewardship.
• Source-to-target mappings.
• Transformation and validation rules.
• Treatment of duplicates and unknown values.
• Historical retention requirements.
• Cutover and rollback procedures.
• Reconciliation evidence.
• Access controls and encryption requirements.

A migration should be repeatable. Scripts should be version-controlled, tested against representative data, logged, and capable of identifying rejected records. Reconciliation may compare counts, totals, key distributions, and sampled records. For high-value data, business owners should approve acceptance criteria.

Transactions and concurrency deserve special attention. A Visual Basic program may have relied on implicit database behavior or user-interface locking. When functions are moved into services, transaction boundaries can change. Developers must determine which operations must be atomic, what isolation is required, and how retries affect duplicate processing.

7. Governance for Visual Basic Development and Modernization

Governance is the system of decision rights, policies, controls, evidence, and accountability that guides technology work. It should enable responsible delivery rather than create paperwork without risk reduction.

7.1 Architecture governance

An architecture review should establish approved runtimes, identity mechanisms, data stores, integration patterns, logging standards, and support obligations. Exceptions should be documented with an owner, justification, compensating controls, expiry or review date, and residual risk.

7.2 Source and configuration governance

Source code should be held in a version-control system with protected branches, peer review, traceable work items, and reproducible builds. Configuration should be separated from code. Secrets must not be embedded in VB source, spreadsheets, scripts, or deployment packages; they should be stored in an approved secret-management facility and rotated according to policy.

Binary dependencies, installers, COM registrations, database scripts, and Office templates should be versioned or otherwise controlled. A software bill of materials is useful for identifying components and licensing or security exposure.

7.3 Change and release governance

A controlled release process links a change to requirements, tests, approvals, deployment evidence, and rollback instructions. Emergency changes may follow an accelerated path, but they should be reviewed retrospectively. Automated pipelines can compile, test, scan, package, and deploy VB.NET applications consistently. For desktop or Office solutions, distribution mechanisms must also address compatibility, signing, endpoint policy, and version coexistence.

7.4 Security governance

Security governance should apply least privilege, separation of duties, secure authentication, authorization checks, input validation, protected transport, secure logging, vulnerability management, and incident response. The principle of least privilege means that a user, process, or service receives only the permissions necessary for its legitimate function.

Particular Visual Basic risks include SQL injection through string concatenation, unsafe deserialization, macro abuse, untrusted file execution, insecure COM exposure, hard-coded passwords, excessive database privileges, and insufficient validation of user-supplied paths. Secure coding standards should provide approved examples for parameterized queries, error handling, logging, and cryptographic operations. Application developers should use established platform libraries rather than inventing encryption or password-storage methods.

7.5 Compliance and records

Depending on context, systems may be subject to privacy, financial, health, accessibility, records-retention, software licensing, or sector-specific requirements. Governance should identify the data controller or owner, lawful or authorized use, retention period, access rights, audit requirements, and breach procedures. Compliance is not achieved by collecting logs indiscriminately; logs should be relevant, protected, access-controlled, and retained according to policy.

8. Testing and Quality Assurance

Legacy modernization has a high risk of semantic regression: the new system runs successfully but produces a different business result. Testing must therefore include behavior, not merely compilation.

A useful testing portfolio includes:

• Characterization tests: document current observable behavior before changing code.
• Unit tests: verify isolated business rules.
• Integration tests: verify database, file, API, and messaging interactions.
• Contract tests: verify agreed API behavior between producers and consumers.
• System tests: validate complete workflows.
• Regression tests: protect previously verified behavior.
• Performance and resilience tests: assess response, throughput, failure handling, and recovery.
• Security tests: identify authorization, input-validation, dependency, and configuration weaknesses.
• User acceptance tests: confirm that business processes remain fit for purpose.

Golden-master testing can compare outputs of the legacy and modern implementations for the same controlled inputs. Differences are not automatically defects: the legacy behavior may itself be wrong. Each difference requires classification as intentional improvement, accepted compatibility change, or defect.

Test data must be protected. Production data should not be copied casually into development environments. Masking, synthetic data, access restrictions, and retention controls are essential when personal or confidential information is involved.

9. Operational Governance and Measurement

Modernized software requires operational ownership. Teams should define service-level objectives, support hours, escalation paths, backup procedures, recovery objectives, monitoring, and incident-management processes.

Two important continuity measures are recovery time objective (RTO) and recovery point objective (RPO). RTO is the maximum acceptable time to restore service after a disruption. RPO is the maximum acceptable amount of data loss measured in time. For example, an RPO of 15 minutes means that recovery should lose no more than approximately 15 minutes of accepted transactions under the stated design and assumptions. These are business requirements, not properties automatically guaranteed by a cloud provider.

Useful measures include deployment frequency, lead time for change, change failure rate, mean time to restore, escaped defects, vulnerability age, test coverage, availability, and user-impacting incidents. Metrics should support learning rather than encourage manipulation. High test coverage does not prove that important behavior is tested, and frequent deployment is not beneficial if failures increase.

10. Worked Application: Modernizing a Manufacturing Scheduling System

Background

The following is an illustrative case. A medium-sized manufacturer operates a Visual Basic 6 scheduling application. It reads production orders from a relational database, allows planners to assign jobs to machines, and exports daily schedules to shop-floor terminals. The application is business-critical, but only two employees understand its database triggers and file-generation rules.

Problem

The application depends on a 32-bit runtime, uses shared network folders, contains several concatenated SQL statements, and has no automated regression suite. A planned operating-system upgrade threatens compatibility. The business also wants browser-based access for regional planners.

Analysis

The modernization team inventories executable files, COM components, database procedures, scheduled jobs, export formats, user roles, and machine identifiers. Workshops reveal that a particular one-character status code has three different meanings depending on the table. Direct replacement would risk losing undocumented scheduling rules. The team therefore classifies the system as high business criticality, high knowledge concentration, high technical risk, and moderate functional change pressure.

Approach

The team selects incremental modernization:

1. Freeze uncontrolled feature growth and place source and database scripts under version control.
2. Build characterization tests around representative scheduling scenarios.
3. Replace embedded credentials with managed identities or protected configuration appropriate to the environment.
4. Parameterize database queries and introduce authorization checks.
5. Create an adapter around the existing scheduling engine.
6. Expose selected read-only schedules through a versioned service.
7. Build a browser interface for viewing schedules while planners continue using the existing client for complex editing.
8. Refactor scheduling rules into testable VB.NET classes as changes are required.
9. Reconcile outputs between old and new components during a controlled parallel run.
10. Retire the old interface only after user acceptance, operational readiness, and rollback criteria are satisfied.

Outcome

The organization avoids a risky “big bang” rewrite. It obtains improved operating-system support, better auditability, and browser-based visibility while preserving validated scheduling behavior. The remaining legacy engine is now bounded by an adapter and monitored interface, making later replacement more feasible.

Learning points

The case demonstrates that modernization can begin with governance, discovery, and characterization testing. It also shows why an API, a new user interface, or a cloud deployment is not sufficient by itself. The essential achievement is controlled reduction of technical and organizational dependence.

11. Economic, Ethical, and Organizational Considerations

Modernization decisions distribute benefits and burdens. A new system may improve management reporting while imposing retraining costs on operational staff. Automation may remove repetitive work but change roles or reduce employment opportunities. Ethical planning requires transparent communication, meaningful participation, accessibility, and fair treatment of affected workers.

Data migration can create privacy risks when records are copied into test environments or cloud platforms. Organizations should minimize data, define legitimate access, encrypt sensitive information, and explain significant changes to affected stakeholders. Automated decision support must be evaluated for bias, explainability, contestability, and accountability, particularly when it influences employment, credit, healthcare, education, or public services.

Vendor selection also creates governance obligations. Proprietary platforms may reduce immediate development cost while increasing long-term lock-in. Open-source components may improve flexibility but still require license compliance, security review, maintenance ownership, and documented provenance.

12. AI and Contemporary Directions

Artificial intelligence can assist legacy modernization, but it should be treated as an engineering aid rather than an autonomous authority. Potential uses include summarizing modules, identifying duplicated code, suggesting dependency relationships, generating test cases, translating comments, detecting suspicious SQL patterns, and helping create documentation from logs and source code.

Risks include hallucinated explanations, incorrect code translation, leakage of confidential source code to external services, reproduction of insecure patterns, licensing uncertainty, and overconfidence in generated tests. Human review, protected development environments, provenance records, static analysis, compilation, execution tests, and security review remain necessary.

Future Visual Basic practice is likely to emphasize interoperability rather than isolated language identity. VB.NET applications may coexist with C#, REST or messaging interfaces, containers or managed hosting, relational and analytical data services, identity platforms, and automated delivery pipelines. Organizations should distinguish the future of the language from the future of applications written in the language: a language may remain useful for maintaining domain-specific systems even as new services use different technologies.

Other important directions include:

• Platform-supported .NET versions and deliberate retirement of unsupported runtimes.
• Zero-trust security models based on explicit verification and least privilege.
• Infrastructure and configuration managed as code.
• Observability through structured logs, metrics, and traces.
• Event-driven integration where asynchronous behavior is justified.
• Platform engineering that provides approved delivery paths for development teams.
• Increased use of formal data contracts and automated compliance evidence.
• Sustainable computing, including efficient workloads and responsible infrastructure use.

These directions should be adopted selectively. Complexity is itself a risk. A small stable application may not benefit from microservices, event streaming, or container orchestration if those technologies add operational burden without meaningful value.

13. Best-Practice Decision Framework

A disciplined modernization program can follow this sequence:

1. Establish business outcomes and constraints.
2. Inventory applications, interfaces, data, owners, and operational dependencies.
3. Assess risk, technical health, change pressure, and feasibility.
4. Preserve behavior with characterization tests where appropriate.
5. Select a strategy for each capability rather than assuming one strategy for the entire portfolio.
6. Define target architecture, security controls, data ownership, and governance gates.
7. Deliver a small but valuable vertical slice.
8. Automate build, test, scanning, packaging, and deployment evidence.
9. Run old and new capabilities in parallel when reconciliation is possible.
10. Measure outcomes and revise the roadmap.
11. Decommission deliberately, including data retention, access removal, license closure, and operational documentation.

The framework is effective only when decision records explain why a strategy was selected and what evidence would justify changing it.

Challenges and Limitations

Modernization is constrained by incomplete knowledge, uncertain costs, staff availability, incompatible data, vendor dependence, organizational resistance, and the possibility that requirements will change during a long program. Technical debt cannot always be eliminated; some trade-offs are rational responses to time, budget, or safety constraints.

A modernization project may fail through excessive ambition, inadequate testing, underestimating data complexity, ignoring users, or treating governance as an approval ceremony. Conversely, excessive caution can preserve an unsafe or unsupported system indefinitely. The appropriate objective is not technological novelty but a defensible balance among value, risk, maintainability, security, and continuity.

Chapter Summary

Legacy Visual Basic systems are valuable but may be difficult to secure, modify, integrate, and operate. Modernization is a socio-technical activity that may involve stabilization, rehosting, replatforming, refactoring, rearchitecting, replacement, or retirement. Effective decisions begin with application, dependency, data, business, and operational discovery.

Layered architecture, adapters, controlled APIs, repeatable data migration, characterization testing, and incremental delivery reduce modernization risk. Governance supplies decision rights, source control, configuration discipline, security controls, release evidence, compliance accountability, and operational ownership. Metrics such as RTO, RPO, deployment performance, defects, vulnerabilities, and restoration time support learning but must be interpreted carefully.

AI can assist code analysis and documentation, but generated outputs require human review and security safeguards. Future Visual Basic practice will increasingly emphasize .NET interoperability, secure APIs, automated delivery, observability, managed infrastructure, and responsible data use. The central professional judgment is to modernize enough to reduce material risk and enable future change without discarding valuable business knowledge.

Key Terms

Legacy system: An important existing system that is difficult to change, operate, secure, or integrate.

Modernization: Deliberate improvement of an existing system’s technology, architecture, process, or operation.

Migration: Movement of software, data, or execution to another platform or environment.

Rehost: Moving an application with minimal code change.

Replatform: Moving to an improved platform with limited functional change.

Refactoring: Improving internal code structure without intentionally changing external behavior.

Rearchitecting: Changing the major structural organization of a system.

Strangler approach: Gradually replacing capabilities around an existing system.

Anti-corruption layer: An adapter that protects a modern model from legacy representations.

Characterization test: A test that records existing observable behavior before change.

Technical debt: Future cost created by expedient technical choices or unresolved constraints.

Governance: Decision rights, policies, controls, evidence, and accountability for technology.

Least privilege: Granting only the access required for legitimate activity.

RTO: Maximum acceptable time to restore service after disruption.

RPO: Maximum acceptable time-based amount of data loss after disruption.

Observability: The ability to understand system behavior through logs, metrics, and traces.

Data stewardship: Responsible oversight of data quality, access, use, and retention.

Software bill of materials: An inventory of components included in software.

Semantic regression: An unintended change in business meaning despite technically successful execution.

Technical risk: The possibility that technology constraints cause loss, failure, insecurity, or inability to change.

Review Questions

Short Answer Questions

1. Why is age alone insufficient to define a legacy system?
2. Distinguish rehosting from refactoring.
3. What is the purpose of an anti-corruption layer?
4. Define RTO and RPO.
5. Why are characterization tests valuable in modernization?

Long Answer Questions

1. Explain the major modernization strategies and identify circumstances in which each may be appropriate.
2. Discuss how governance supports secure and maintainable Visual Basic development.
3. Describe a layered target architecture for a modernized VB.NET application.
4. Explain the principal risks of legacy data migration and propose controls for reducing them.
5. Critically evaluate the use of AI-assisted code analysis and code generation in legacy modernization.

Analytical / Application Questions

1. An organization has a stable VB6 payroll system with high compliance requirements, limited documentation, and no immediate functional expansion. Recommend a modernization strategy and justify it using technical, business, and governance factors.
2. A VB.NET application produces different invoice totals after its database layer is replaced. Design an investigation and testing plan to determine whether the difference is a defect, an undocumented legacy rule, or an intentional change.
3. Develop a phased modernization roadmap for a Visual Basic manufacturing system that must remain available during migration. Identify dependencies, governance gates, testing evidence, rollback conditions, and measures of success.

Multiple Choice Questions with Answers

Question 1

Which statement best describes legacy modernization?

A. Replacing every old application with microservices

B. Improving an existing system’s fitness while managing continuity and risk

C. Changing the programming language without analyzing behavior

D. Moving all source code to a public cloud immediately

Correct Answer: B. Improving an existing system’s fitness while managing continuity and risk

Question 2

What is the principal purpose of characterization testing?

A. To measure developer productivity

B. To document existing observable behavior before changes are made

C. To replace security testing

D. To determine the licensing price of a runtime

Correct Answer: B. To document existing observable behavior before changes are made

Question 3

Which modernization strategy moves an application with minimal code change?

A. Rehost

B. Refactor

C. Rebuild

D. Retire

Correct Answer: A. Rehost

Question 4

What does an anti-corruption layer primarily do?

A. Deletes obsolete records automatically

B. Translates between legacy representations and a modern model

C. Prevents all database transactions

D. Compiles VB6 code into machine language

Correct Answer: B. Translates between legacy representations and a modern model

Question 5

Which practice is most appropriate for database queries that use user-supplied values?

A. Concatenating values into SQL strings

B. Disabling authorization checks

C. Using parameterized queries

D. Storing credentials in source code

Correct Answer: C. Using parameterized queries

Question 6

An RPO of 15 minutes primarily specifies what?

A. The maximum acceptable service restoration time

B. The maximum acceptable time-based amount of data loss

C. The maximum API response time

D. The duration of a software license

Correct Answer: B. The maximum acceptable time-based amount of data loss

Question 7

Which item is an example of governance evidence?

A. An undocumented verbal deployment instruction

B. A traceable change record linked to tests and approval

C. A developer’s personal copy of an installer

D. An unreviewed generated code fragment

Correct Answer: B. A traceable change record linked to tests and approval

Question 8

Why can a successful compilation fail to demonstrate modernization success?

A. Compilation never checks syntax

B. The application may compile while changing business behavior

C. Compiled programs cannot access databases

D. Compilation automatically removes all defects

Correct Answer: B. The application may compile while changing business behavior

Question 9

Which is a significant risk of using generative AI with confidential legacy source code?

A. The code will always become strongly typed

B. Confidential information may be disclosed to an unauthorized service

C. The application will automatically pass acceptance testing

D. The database will become normalized automatically

Correct Answer: B. Confidential information may be disclosed to an unauthorized service

Question 10

Which principle grants users and services only the permissions required for legitimate work?

A. Least privilege

B. Open access

C. Maximum availability

D. Unrestricted delegation

Correct Answer: A. Least privilege