Remote Server Decommission Process

The purpose of this document is to track the process for decommissioning a FullCount remote server as part of the transition for the client to be centrally hosted or if the client is leaving FullCount.

The first step by the project lead, is to understand and establish the following questions with the community contact:

• What is the expected go-live for transition to central servers or decommission?
• How long and who at the community need access to the old server? (reporting, month end close, etc.)
• What is the intended use of the server after it is decommissioned by the community?
• Would the community like to update their terminals to the newest OS version as part of this conversion process? This step is not necessary, but this gives us a good opportunity to update.

Once these are established, schedule a copy down and/or decommission date with the FullCount development team. Below is a rough outline of that copy down and/or decommission process.

Before Go-Live

• Populate data from remote to central database using spreadsheets and scripts
• Spreadsheet located at: http://sourcecontrol.fullcount.net/repos/database/trunk/processes/implementation/import_templates/Copyover Data Template.xlsx.
• SQL scripts are located at http://sourcecontrol.fullcount.net/repos/database/trunk/processes/implementation/data-copyover-pre_import.sql and http://sourcecontrol.fullcount.net/repos/database/trunk/processes/implementation/data-copyover-post_import.sql
• Confirm the following:
• Departments.DEFAULT_TABLE_AREA_ID
• Modes.DEFAULT_CUSTOMER_ID
• Test that data was loaded correctly
• Determine users who will need access after go-live
• select user_profile_id, user_name, last_name, first_name from t_user_profiles where last_login_bo_4_0 > add_months(sysdate,-6) and project_manager = 'N' and account_status = 'A'  and deleted = 'N' order by upper(last_name), first_name;
• If using ADT integration, coordinate time for moving of services from remote to central.

Below is a list of things that will need to be checked to mitigate any potential issues:

• Update start date of meal plans and charge accounts to current periods. Update first order number to be 1.
• update charge_accounts set first_period_start_date = to_date(<Date>,'mm/dd/yyyy') where community_id = <CommunityId>;
  update community_plans set first_period_start_date = to_date(<Date>,'mm/dd/yyyy') where community_id = <CommunityId>;
  update communities set next_order_number = 1 where community_id = <CommunityId>;
  update user_profiles up set global_user_profile_id = (select global_user_profile.global_user_profile_id from global_user_profiles global_user_profile where up.email = global_user_profile.email) where project_manager = 'Y' and default_community_id = <CommunityId> and global_user_profile_id is null;
• Check for duplicate Username/Passwords on Central Servers.
• select user_name, first_name, last_name, default_community_id, created_date, created_by, pos_operator_code from fc_obj_owner.user_profiles where lower(user_name) in (
  select lower(user_name) from fc_obj_owner.user_profiles
  where deleted <> 'Y' and account_status = 'A'
  group by lower(user_name)
  having count(*) > 1)
  and deleted <> 'Y' and account_status = 'A'
  order by upper(user_name), user_profile_id, default_community_id;
• Compare Community Settings via Community page in back office
• Check if community has customer photos. If they do, create subtask for moving the photos and assign to Rick.
• Determine if community needs to be added to an existing enterprise.
• Run remote to central verification report.
• Script is located at http://sourcecontrol.fullcount.net/repos/database/trunk/processes/implementation/remote_to_central_data_verification_report.sql.
• For remote servers with a 10g database, the script will need to be run using sqlplus on the server itself.
• Connect to remote server.
• Log in as oracle user.
• Connect to sqlplus.
• Copy/paste script contents.
• Enter community id.
• Copy/paste results to Verification Report tab in Excel spreadsheet.
• For the central database server and remote servers with an 11g database, the script can be run in SQLDeveloper.
• Connect as appropriate database user.
• Open script.
• Open Dbms Output view.
• Click green plus icon (Enable DBMS_OUTPUT for connection) for the appropriate database connection.
• Run script as appropriate database user.
• Copy/paste results from Dbms Output to Verification Report tab in Excel spreadsheet.
• Verify Results column in Verification Report tab to see if any counts do not match. Investigate any inconsistencies.

Night Before Go-Live

• Change host location on computers from remote to central. Update COMMUNITY_ID, HOST_LOCATION_ID, and ENABLE_RP to reflect new values.alter table computers disable constraint FK_COMMUNITY_CONF_CMID_HLID;
• alter table computers disable constraint FK_COMMUNITY_CONF_CMID_HLID;
  update community_config set host_location_id =  1, rp_enable = 'NO' where community_id = <Community Id>;
  update computers set hosting_location_id = 1 where hosting_location_id = <Host Location Id>;
  alter table computers enable constraint FK_COMMUNITY_CONF_CMID_HLID;
• Inactivate users who do not need access to the system after go-live.
• --Run on remote server
  update t_user_profiles set account_status = 'I', modified_by = '', modified_date = sysdate
  where project_manager = 'N' and user_profile_id not in (<Comma separated list of user profile ids>) and account_status = 'A' and deleted =  'N';
  commit;
  update t_user_profiles set user_name = user_name || '-old', modified_by = '', modified_date = sysdate
  where user_profile_id  in (<Comma separated list of user profile ids>) and account_status = 'A' and deleted =  'N';
  commit;
• Import gift cards with balances, if applicable.
• Import plan balances, if applicable
• Manually download new config file on Print Servers and Kitchen Display Systems and restart application.
• Shutdown and disable POSWebApplication service.

Post Go-Live

Update Zoho

Update Tracker

• Change Host Location on Process tab
• Add entry to Notes specifying when the migration occurred.

Update FullCount Customers Map

• Change marker on map from Red to Blue.

Update J:\FullCount\FC - Implementations\Username Community Suffixes.xlsx

• Change cells for community and abbreviation from Blue to Green if migrating from on-premise to cloud-hosted.

Email marketing@fullcount.net about go-live so they can update Hubspot.

Once the go-live date has happened and the community no longer needs access to the server. Begin planning a date to decommission the server with the community and the FullCount tech team.

Shutdown and Disable Services

Below are the steps that FullCount will need to take to shutdown and disable services on the server.

1. Copy latest datapump (fc_obj_owner) file to fcadmin01 from remote server
2. Archive (copy and compress) latest datapump file to fcadmin01:/srv/remote_backups/archives/
3. Delete latest datapump file in /oracle/XE/remote_backups on fcadmin01.
4. Shutdown and disable the following services on remote server:
1. Apache
2. backoffice
3. FullCount
4. POSWebApplication
5. Oracle XE
5. Disable cron jobs on remote server:

1. fullcount-database-backup

6. Leave the VM running for a period of time (2 weeks?).
7. Shutdown and delete the VM.

Mark Community and Hardware As Inactive

After the VM has been shutdown and deleted, the community, terminals, tablets, server, etc. need to be marked as inactive in the following tables:

• COMMUNITIES
• COMMUNITY_CONFIG
• COMPUTERS

Script located at http://sourcecontrol.fullcount.net/repos/database/trunk/processes/decommission/remote_server_decommission.sql

Shutdown The Server

Work with someone at the community to shutdown and power off the server.

Cleanup Systems Items

Remote Servers

• Ansible cleanup
• Remove files for customer under /srv/ansible/inventory/group_vars/ on fcadmin01
• Remove files for customer in SVN (http://sourcecontrol.fullcount.net/repos/ansible/trunk/inventory/group_vars/
• KeePass cleanup
• SSL Certificates.kdbx
• Servers – Prod.kdbx
• Prometheus cleanup
• Remove VM from target files in /etc/prometheus/targets on prometheus01

Coordinate with Accounting

If the customer is leaving FullCount, be sure to notify Accounting and confirm final invoice has been sent.