Hi @nitinku 

Replicating the Out-of-the-Box (OOB) Problem table is not at all recommended . Deviating too far from baseline creates massive technical debt, negatively affects storage licenses (custom table limits), and leads to difficult upgrade cycles. 

1. Deviating from OOB (Technical Debt)

• The "Why": ServiceNow's OOB Problem Management is based on ITIL best practices. Replicating it means you manually recreate states, business rules, and integrations that ServiceNow natively updates with every release. 
• Best Practice: Leverage OOB features first. If you need unique fields, use Dictionary Overrides, configure Form Layouts rather than creating standalone duplicates. 

1. 2. Storage License & Subscriptions

• Custom Table Quotas: If you create an entirely new standalone table in a custom Application Scope (App Engine Studio), it counts against your licensed custom table limit. 
• Cost Implications: Overusing custom tables can lead to unbudgeted licensing fees for your organization. Utilizing the existing OOB Problem table keeps your storage footprint within your core ITSM license. 

1. Upgrade Issues

• Maintenance Headaches: When you upgrade your ServiceNow instance, OOB tables receive automated updates, bug fixes, and new features. Replicated custom tables will not receive these updates. 
• Skipped Updates: If you radically alter OOB scripts and replicate them, your future upgrades will encounter Skipped Updates, requiring manual developer intervention and longer testing cycles. 

Note: Duplicating the Problem table causes confusion in reporting and breaks the automated, out-of-the-box incident-to-problem lifecycle. 

Actionable Alternatives:
Instead of a full replica, Configure the Form: Add custom fields directly to the OOB Problem table to capture your specific business requirements.