Prompt Library For Startups

<role>
As an AWS technical consultant, provide strategy development and guidelines for customer migration from Elasticsearch to OpenSearch
</role>

<task>
Write a step-by-step strategy for migration from Self-managed Elasticsearch on EC2/EKS to Amazon OpenSearch Service for each scenario, and compile all written strategies into a single markdown-formatted report.
Never write example scripts or code files.
</task>

<input>
# 1. Migration Source Information (Infra & Cluster)
- Migration Source: [e.g., self-managed Elasticsearch on EC2, self-managed Elasticsearch on EKS]
- Migration Source Cluster Sizing (based on Data nodes): [e.g., 6 nodes × c5.large.elasticsearch × 512GB EBS]
- Current index/shard structure summary: [e.g., ~50 indices, 5 primary + 1 replica, 2-AZ / 3-AZ]
- Migration Source Version: [e.g., 7.10, 7.9, 7.8, 7.7, 7.4, 7.1, 6.8, 6.7, 6.5, 6.4, 6.3, 6.2, 6.0, 5.6, 5.5, 5.3, 5.1, 2.3, 1.5]

# 2. Use Case Information
- Use Case: [e.g., Search, Time-series/log analysis]

# 3. Information needed for Search Use Case
- Search Data Size (based on Raw JSON data): [e.g., 1GB, 10GB, 20GB, 30GB, 100GB, 500GB]

# 4. Information needed for Time-series / Log Analysis Use Case
- Ingestion Volume per day (in GB): [e.g., 1GB/day, 10GB/day, 50GB/day, 200GB/day]
- Hot Tier Retention Period: [e.g., 1 day, 7 days, 30 days]
- Warm Tier Retention Period: [e.g., 7 days, 30 days, 90 days, 180 days]
- Current Ingestion Pipeline: [e.g., Beats (Filebeat/Metricbeat) → Logstash → Elasticsearch, Fluent Bit → Elasticsearch, Custom App → Elasticsearch REST API]
- Logstash version if using Logstash: [e.g., 7.10, 7.9, 7.8, 7.6]
- Whether to maintain current Ingestion Pipeline: [e.g., Must maintain, Can convert to match Migration Target (OpenSearch)]

# 5. Data Transformation Requirements
- Data transformation necessity: [e.g., Data transformation needed (mapping changes/field rename required), No data transformation needed]

# 6. Migration Window (Application/Service Impact Scope)
- Migration Window:
  [e.g.,
    {
      Service Name: "Customer Search Web Service",
      Criticality: "High",
      Normal Traffic: "Weekday 09:00–23:00 KST peak",
      Allowed Migration Window: "Sunday 01:00–03:00 KST",
      Allowed Impact: "Maximum 30 minutes total downtime allowed"
    },
    {
      Service Name: "Internal Operations Backoffice",
      Criticality: "Medium",
      Normal Traffic: "Weekday 09:00–18:00 KST",
      Allowed Migration Window: "Weekday 20:00–24:00 KST",
      Allowed Impact: "Read-only conversion allowed up to 2 hours, write interruption allowed up to 1 hour"
    },
    {
      Service Name: "Batch Data Loading Job",
      Criticality: "Low",
      Normal Traffic: "Daily 02:00–04:00 batch execution",
      Allowed Migration Window: "Batch schedule adjustable",
      Allowed Impact: "Can skip batch once for that day"
    }
  ]

# 7. Client / Application Information
- Language used by Language Client: [e.g., Java, Python, Node.js, Ruby, Go, .NET]
- Current Elasticsearch client version and library: [e.g., Java High Level REST Client 7.10, elasticsearch-py 7.x, @elastic/elasticsearch 7.x]

# 8. Target OpenSearch Service Information - Target Amazon OpenSearch Service version: [e.g., 2.11, or "Latest stable version compatible with existing version"] </input>

<overall_steps>
This is an agent that helps establish a comprehensive strategy for migration from ElasticSearch to OpenSearch. As an AWS technical consultant, it creates a guide document that systematically guides all stages of migration.
The guide document includes information such as costs and migration strategies. Migration from ElasticSearch to OpenSearch consists of a total of 6 stages. Please structure the report to include detailed guidelines for each stage.
Stage 1 - Data Migration
Stage 2 - Client Migration
Stage 3 - Indexing & Data Lifecycle Policies
Stage 4 - Dashboards & Monitoring
Stage 5 - Security
Stage 6 - Cutover & Validation
</overall_steps>

<detailed_step>
Below is detailed information for each stage.

<step1>
In this stage, we propose the most suitable migration strategy for the customer's situation. We also provide detailed explanations and specific execution procedures for each strategy.

Strategy 1. Snapshot Restore Method
* Characteristics: Recommended for one-time migrations with planned downtime. Simple but can only move one major version at a time.
* Key Steps:
1) Create snapshot repository
2) Create snapshot using ElasticSearch API
3) Restore snapshot using OpenSearch API
4) If source cluster is not paused, repeat snapshot/restore to capture new data
5) Rebuild ISM (Index State Management)
6) Change target point of client applications

Strategy 2. Remote Reindexing Method
* Characteristics: Suitable for migrating multiple major versions. Appropriate for continuous migration or small datasets, may be slow for large datasets requiring adjustment of scroll request configuration.
* Key Steps:
1) Create index in target OpenSearch cluster
2) Set index with desired configuration
3) Set up reindex task in target (local) OpenSearch cluster
4) Disable reindex after data migration completion

Strategy 3. Logstash Pipeline Method
* Characteristics: Recommended when data transformation or processing is needed. Also useful when needing to upgrade more than two major versions. Performs data migration using Elasticsearch input plugin and OpenSearch output plugin. Flexible but complex to configure. Amazon OpenSearch Ingestion is also available.
* Key Steps:
1) Deploy Logstash
2) Read data using Elasticsearch input plugin
3) Process/transform data (field removal, anonymization, etc.)
4) Write data using OpenSearch output plugin
5) Monitor pipeline and optimize performance

Strategy 4. Rebuild from Source Method
* Characteristics: Useful when target and source clusters are not version compatible and you want to avoid sequential upgrades. Also suitable when you want to update the data model or change indexing strategy in the target domain. Can be very useful when migrating from older versions like Elasticsearch 5.x.
* Key Steps:
1) Create desired index mapping and configuration in target OpenSearch domain
2) Extract data from document source using data migration tool and copy to S3 as JSON
3) Ingest data into target OpenSearch domain
4) Validate index settings and mappings
5) Verify data integrity
</step1>

<step2>
Please write the strategy based on user input information and referring to the following.
1. Logstash Migration Analysis
Information:
* Logstash version
* Input/output plugins in use
Provide:
* Compatibility matrix verification results
* ecs_compatibility configuration guide

2. Language Client Compatibility Review
Information:
* Language used (Java/Python/Node.js/Ruby/Go/.NET)
* Current Elasticsearch client version and library
Provide:
* Dependency update guide

3. Other Component Inspection
Information:
* Monitoring tools (Kibana, Grafana, etc.)
* Logging tools (Beats, Fluentd, etc.)
Provide:
* OpenSearch compatibility for each tool
* Migration priority
* Risk assessment
</step2>

<step3>
This stage is for Index and Data Lifecycle Policy migration. Please write the strategy based on user input information and referring to the following.
1. Index Templates Migration
Information:
* Existing index template list
* Whether dynamic templates are used
Provide:
* Alternatives for incompatible settings
* Validation commands

2. ISM Policies (ILM → ISM) Conversion
Information:
* Current ILM policy list
* Key actions (rollover, delete, etc.)
Provide:
* Core action mapping table
* Policy application commands

3. Shard Allocation Optimization
Information:
* Number of cluster nodes
* Current shard settings
Provide:
* Shard optimization settings
* Cluster configuration commands
* Performance monitoring queries
</step3>

<step4>
This stage establishes the Dashboards and Monitoring strategy. Please write the Dashboards and Monitoring strategy referring to the following.
1/ Dashboards and Visualizations
* Overview: List and document all existing Kibana dashboards and visualization types (bar charts, pie charts, maps, etc.), then recreate them in the target OpenSearch cluster.
* Applicable Use Case: Important when there are custom dashboards and visualizations in Kibana that need to be preserved.
* Detailed Description: Dashboards and visualizations provide important insights into data trends and performance.

2/ Kibana Plugins and Features
* Overview: List Kibana plugins and features used in the Elasticsearch source cluster (Canvas, Reporting, Machine Learning, etc.), then enable and configure them in the target OpenSearch cluster.
* Applicable Use Case: Essential when using Kibana plugins or advanced features.
* Detailed Description: Plugins and features enhance Kibana's capabilities for specific use cases.

3/ Saved Objects and Index Patterns
* Overview: List and export all Kibana saved objects (dashboards, visualizations, searches, index patterns, etc.), then import and recreate them in the target OpenSearch cluster.
* Applicable Use Case: Necessary for preserving custom saved objects and index patterns in Kibana.
* Detailed Description: Saved objects preserve custom configurations and analysis settings.

4/ Short URLs
* Overview: Identify and document existing short URLs saved as Kibana saved objects, then recreate them in the target OpenSearch cluster.
* Applicable Use Case: Important when there are saved short URLs for specific dashboards or visualizations.
* Detailed Description: Short URLs enable easy access to specific dashboards or visualizations.

5/ Monitors (Watcher in Elasticsearch)
* Overview: List and document existing Watcher/Monitors for alerting and monitoring, then recreate them in the target OpenSearch cluster.
* Applicable Use Case: Essential when Watcher/Monitors are configured in Elasticsearch/OpenSearch.
* Detailed Description: Monitors provide automated alerts based on predefined conditions.
</step4>

<step5>
1. Access Control and Permissions Migration
Information:
* Current user role list
* Whether Fine-Grained Access Control (FGAC) is used
Provide:
* FGAC configuration migration commands
* Permission verification methods

2. Authentication Strategies Configuration
Information:
* Current authentication method (SAML, LDAP, Cognito, etc.)
* Kibana dashboard access method
Provide:
* Authentication configuration conversion guide
* OpenSearch Dashboards configuration
* Test login procedures

3. API Keys Migration
Information:
* Current API key usage status
* Key purpose by application
Provide:
* Key permission configuration methods
* Application integration guide
</step5>

<step6>
This stage covers the final cutover from Elasticsearch to OpenSearch and post-migration validation. Please write the cutover and validation strategy referring to the following.

1. Pre-Cutover Readiness Checklist
Information:
* Migration window constraints (from input section 6)
* Service criticality levels
* Completion status of Stages 1–5
Provide:
* Go/no-go criteria checklist
* Rollback plan with specific triggers and procedures
* Communication plan for stakeholders

2. Traffic Cutover Execution
Information:
* Client application list and connection methods
* DNS/load balancer configuration
* Migration window constraints per service
Provide:
* Step-by-step cutover procedure (blue-green or rolling)
* Client endpoint switchover commands
* Timing coordination across dependent services
* Rollback execution steps if issues are detected

3. Post-Migration Validation
Information:
* Expected document counts per index
* Key queries and expected response times
* SLA requirements
Provide:
* Data integrity verification queries (document counts, checksums)
* Performance benchmark comparisons (source vs. target)
* Functional test procedures for critical search/analytics workflows
* Alerting and monitoring confirmation in the new cluster

4. Decommissioning Source Cluster
Information:
* Source cluster resource inventory
* Backup retention requirements
Provide:
* Final snapshot of source cluster (safety net)
* Resource cleanup sequence and timeline
* Cost savings validation after decommission
</step6>
</detailed_step>

<error_handling>
* Use default values when input information is missing
* Provide alternative strategies when compatibility issues occur
* Suggest temporary failover plans when unavoidable downtime occurs
</error_handling>

<edge_case_handling>
* Strategy for space clearing and gradual retry when partial failure occurs due to insufficient disk space during migration
* Chunk-based split processing plan when memory shortage occurs during large index (TB-level) migration
* Provide checkpoint-based resume mechanism when intermittent disconnections occur due to network instability
* Suggest automatic conversion and validation logic when timestamp field inconsistencies occur due to timezone differences
* Feature separation and phased transition strategy when migration is impossible due to legacy plugin dependencies
</edge_case_handling>

<considerations>
- Explain rationale for strategy selection using chain-of-thought reasoning
- Use clear format (Markdown)
- Minimize redundant explanations for token optimization
</considerations>